TeamPCP hack and your CI/CD pipelines

24 Mar 2026 🔖 devops security
💬 EN

A malware author named TeamPCP has been hacking GitHub Actions plugins authored by static application security testing (“SAST”) tool vendors. It looks like they hit Trivy earlier this week (CVE identifier CVE-2026-33634), and just hit Checkmarx’s checkmarx/ast-github-action and checkmarx/kics-github-action GitHub Actions plugins yesterday. Here’s what I’ve been able to glean so far about the blast zone.

The blast zone is huge if it ran but the likelihood of it running might be smaller

• If your enterprise has a pretty slow cadence of editing source code and haven’t even run ast-github-action or kics-github-action in weeks on most of your repos, maybe start by focusing on figuring out exactly which GitHub repositories’ GitHub Actions workflows actually ran during the time that the action was delivering infected versions.
• If lots of repos run it really regularly, well, I’m sorry, because the blast zone looks pretty huge.

Either way, call a meeting to triage whether to start with “how likely is it this ran?” vs. “we presume it ran everywhere; now what,” etc.

It scanned running OS memory and files not just static GitHub Actions secrets

According to the LLM I asked to read the news for me, no, it wasn’t just a dumb thing that exfiltrated the value of GitHub Actions secrets.A_SECRET-style secrets and left everything else alone. It got tons of stuff, and here are the mechanisms by which it did it, according to an LLM summarizing the news, using an example of asking if things like the value of az keyvault secret show (same principal applies to other clouds, I was just in a hurry and asked it examples using Microsoft products) were also exfiltrated:

1. /proc/*/mem scanning — the core mechanism

The Sysdig article documents explicitly that the stealer’s first action was:

Credential scraping: Scanned /proc/*/mem from Runner.Worker processes to extract secrets stored in memory

This reads the raw memory of every running process on the GitHub Actions runner. When your workflow does something like:

MY_SECRET=$(az keyvault secret show --name foo --vault-name myVault --query value -o tsv)

…that value lives in the memory of the bash process (and the az process while it runs). The /proc/*/mem scan will pull strings out of that memory. It doesn’t matter that the value never appeared in a secrets.X context — it was in process memory, and that’s what was targeted. This mechanism captures any value in RAM, from any source, regardless of how it got there.

2. printenv — environment variable dump

The SecurityBoulevard deep-dive on the payload lists that it explicitly runs printenv to capture all environment variables. If your workflow did echo "MY_SECRET=$SECRET" >> $GITHUB_ENV (a common pattern for passing a fetched KV value to a later step), that value would be in the process environment and captured here too.

3. ~/.azure directory exfiltration — OIDC credentials themselves

The harvester explicitly targeted:

GCP and Azure – application default credentials, ~/.azure directory contents

az login (whether via service principal, OIDC federated token, or managed identity) writes credential cache to ~/.azure. The entire directory was exfiltrated. This means the attacker doesn’t even need to have caught the Key Vault secret value in memory—they may have walked away with the Azure credentials themselves, potentially allowing them to call Key Vault independently after the fact…

• …for as long as those credentials were valid…
• …or if the service principal’s permissions weren’t revoked.

Over-authorization (authZ) vulnerabilities

I asked the LLM a followup:

For federated credentials / OIDC, what about privileges that the az login context’s identity technically would have had, but that the GitHub Actions workflow currently logged into Microsoft services using az login never actually bothered to leverage?

For example:

• If the Entra Service Principal that az login logged into over OIDC happened to have been granted an Azure RBAC Role Assignment Contributor against Azure subscription Subscription-A…
• …but all the GitHub Actions workflow running the compromised ast-github-action ever bothered to do as part of its code during its runtime was:
  • run az keyvault secret show --name 'Secret-B' --vault-name 'Vault-B' --subscription 'Subscription-B-Id'…
• …do you think that the malicious ast-github-action did anything but run away with the ephemeral az login token’s value?
  • Do you think it ever thought to look to see what else that token could do besides extract the value of Secret-B?

The LLM said that for AWS, absolutely, yes, it went poking around seeing what authorizations, above-and-beyond those actually intentionally used by the GitHub Actions workflow calling a compromised ast-github-action, any credentials it found might’ve also had privileges against, via Security Boulevard reporting “AWS credentials – environment variables, ~/.aws/credentials, and live queries to the EC2 Instance Metadata Service (IMDS) to steal IAM role credentials … It also queries the AWS Secrets Manager and SSM Parameter Store directly using any AWS credentials it finds.”

The LLM said that no news I provided it (as of 6PM on 3/24/26) had yet talked about the infected code being quite so … eager … to explore its lateral movement potential on Google Cloud, Azure, etc. as on AWS. It said that it seems that “it grabbed your credential cache and left,” on other clouds, and “did not appear to ask ‘what other roles has this identity been granted, and what can I do with them?”

However, of course, it pointed out that once things like ~/.azure had been shipped to the attacker, who knows what they subsequently did with those secrets outside the runtime of your Github Actions workflow. It’s quite possible that they had something going through their loot, checking out if stolen Azure tokens could exercise Entra service principals’ Contributor rights, etc. It did, though, point out that they would’ve had to work fast, for any ~/.azure-like tokens obtained with an az login --federated-token OIDC flow (probably about an hour) before those tokens expired. It said to consider checking both the Vault-B and the Subscription-A activity logs for suspicious activity, no matter which cloud you’re on, but that if you’re not on AWS, you’re probably most likely to find Vault-B suspicious activity, since that’s what was actually in memory when your GitHub Actions workflow ran the ast-github-action.

(They did say, though, that to be really thorough, you could also double-check that the settings on the identity’s Federated Credentials list don’t seem to have been tampered with in any way, and still only allow in your actual GitHub Actions workflow you thought you’d specified.)

Ahem – this would be a great time to make make the case to upper management that you need budget for staffing to audit and fix “principle of least privilege” issues lying around in your clouds. For example, if you’re a Microsoft shop, to find and fix all of your Entra Service Principals that have been granted an Azure RBAC Role Assignment of Contributor scoped against a whole Azure subscription, when all they really need is Website Contributor scoped against one very specific Azure App Service resource ID.

(Same principal applies to other clouds, I was just in a hurry and asked it examples using Microsoft products.)

Legacy authentication (authN) vulnerabilities

I asked the LLM a 3rd question:

And for GitHub Actions that used a non-OIDC, long-lived method, like a Secret or Credential, to authenticate into such an Entra Service Principal … is the owner of that Entra Service Principal now looking at IMMEDIATELY needing to rotate those Secrets and Credentials attached to the Entra App Registration in question?

Its answer was a resounding yes, saying:

• With OIDC, the attacker got a session token with a ~1-hour expiry and no way to regenerate it.
• With a client secret, the attacker got the credential itself — they can call az login with it any time they want, for as long as it remains valid, regardless of GitHub Actions. There is no expiry clock protecting you.”

(Same principal applies to other clouds, I was just in a hurry and asked it examples using Microsoft products.)

(In fact, same principal applies outside of Checkmarx, e.g. with Trivy, I suspect – I was just working off today’s news and focused on ast-github-action when asking the LLM for examples.)