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.

Big blast zone; smallish time window?

• From deciphering news reports, it looks like the whole thing both blew up and got remediated, on the Checkmarx side, this week? So 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 against 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.

Dynamic OS memory and filesystem exfiltration, not just static GitHub Actions secrets

According to the LLM I asked to read the news for me, no, the malicious actions wasn’t just a dumb script that exfiltrated the value of GitHub Actions secrets.A_SECRET-style secrets and left everything else alone.

The malicious action ran away with tons of stuff.

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 were also exfiltrated:

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

1. /proc/*/mem

According to Sysdig, the malicious action “Scanned /proc/*/mem from Runner.Worker processes to extract secrets stored in memory.”

Apparently that reads the raw memory of every running process on the GitHub Actions runner.

So if the workflow is programmed to do something like:

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

…then that value would live in the memory of the bash process (and the az process while it runs), and the /proc/*/mem scan would be able to pull strings out of that memory.

/proc/*/mem apparently is capable of capturing any value in RAM, from any source, regardless of how it got there.

2. printenv

Security Boulevard reported that the malicious action explicitly runs printenv to capture all environment variables.

So 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 via printenv in addition to via /proc/*/mem.

3. OIDC tokens via things like the ~/.azure directory

The LLM reported that the malicious actionalso explicitly targeted:

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

Apparently the az login command caches credentials into ~/.azure, and this entire directory was exfiltrated.

Meaning that not only might they have walked away with the value of the Key Vault secret via /proc/*/mem or printenv, but they could also simply call az keyvault secret show after the fact, using your stolen Azure credential.

(Though if you’d used az login over OIDC, they would’ve only had about an hour to do it before the contents of ~/.azure – or whatever other clodu provider is applicable – expired.)

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 principle 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 principle applies to other clouds, I was just in a hurry and asked it examples using Microsoft products.)

(In fact, Same principle applies outside of Checkmarx, e.g. with Trivy, LiteLLM, or wherever else this ends up spreading, I suspect – I was just working off today’s news and focused on ast-github-action when asking the LLM for examples.)