Treat every Vercel token, deploy hook and automation bypass secret in CI as exposed if a runner pulled trivy-action between about 17:43 UTC March 19 and 05:40 UTC March 20, 2026, a compromised setup-trivy tag, Trivy v0.69.4, the v0.69.5 or v0.69.6 images, or litellm 1.82.7 or 1.82.8. Rotate them this week and move cloud access to OIDC where supported.
What happened in the Trivy and LiteLLM compromises?
Attackers used compromised credentials to push malicious Trivy releases and tags, and LiteLLM believes that breach led to its own poisoned PyPI packages. The Trivy advisory GHSA-69fq-xp46-6x23, published March 21, 2026, says that on March 19, 2026 a threat actor published a malicious Trivy v0.69.4 release. The same actor force-pushed 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware and replaced all 7 tags in aquasecurity/setup-trivy with malicious commits.
On March 22, 2026, compromised credentials were used again to publish malicious Trivy v0.69.5 and v0.69.6 images on DockerHub. The advisory lists trivy-action below 0.35.0 and setup-trivy below 0.2.6 as affected, with 0.35.0 and 0.2.6 as the patched versions. For the Trivy binary it lists 0.69.4 as affected and 0.69.3 as the patched version.
LiteLLM’s maintainers say litellm 1.82.7 and 1.82.8 were live on PyPI on March 24, 2026 from 10:39 UTC for about 40 minutes before PyPI quarantined them. Their exposure guidance covers a wider window. Anyone who installed or upgraded via pip on March 24 between 10:39 UTC and 16:00 UTC may be affected. So may Docker images built in that window with an unpinned install, and projects that pulled LiteLLM in as a transitive, unpinned dependency.
LiteLLM says the compromised versions appear to have included a credential stealer. LiteLLM says the stealer was designed to scan for environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords. It was also designed to encrypt that data and send it in a POST request to models.litellm.cloud, which is not an official LiteLLM domain. LiteLLM marked the investigation as active. Its current reading is that a maintainer’s PyPI account may have been compromised, that stolen credentials from the Trivy compromise reportedly reached its publishing pipeline through Trivy in its CI/CD security scanning workflow, and that the attacker bypassed the official workflows to upload directly to PyPI.
LiteLLM lists users of the official LiteLLM Proxy Docker image, users of LiteLLM Cloud, and users on v1.82.6 or earlier who did not upgrade during the window as not affected. A clean v1.83.0 shipped from a new pipeline with isolated environments, stronger security gates and safer release separation.
Why does this matter for Vercel credentials in CI?
It matters because a Vercel token passed to a deploy job as an environment variable is the kind of secret the LiteLLM stealer scanned for. The Trivy advisory calls the rewritten trivy-action tags credential-stealing malware. So the cautious reading is to treat every secret in an affected job as exposed. If an affected step ran in the same job as a deploy, assume it could reach that token.
A secret copied before a tag was fixed stays valid until you rotate it.
The teams affected are those whose pipelines pulled any listed version, directly or transitively, while holding Vercel, cloud or publishing credentials in the same job.
Which Vercel tokens in CI are still static?
Every Vercel credential a pipeline reads from a stored secret is static. Vercel documents how to create a deploy hook and how permissions work for Protection Bypass for Automation, so both belong on the inventory next to account tokens.
| Credential | Where to look | This week |
|---|---|---|
| Any Vercel token stored for CLI deploys | Repository, organization and environment secrets in CI | Replace it if any job that could read it ran an affected version |
| Deploy hook | CMS webhooks, scheduled jobs, integration settings | Treat it as a secret. Recreate any hook that appeared in CI logs or variables |
| Protection Bypass for Automation secret | End-to-end test jobs and preview checks | Check Vercel’s bypass docs for how to replace it, and review who can read it |
| Cloud keys in build variables (AWS, GCP, Azure) | Build environment variables and CI secrets | Rotate, then move to OIDC federation |
| Package publish tokens (PyPI) | Release workflows | Revoke the stored token and move publishing to OIDC |
Which credentials should move to OIDC first?
Cloud provider keys and package publishing tokens should go first, because GitHub Actions already documents OIDC for those paths. Its docs carry OIDC guides for AWS, Azure, Google Cloud Platform, HashiCorp Vault and PyPI. LiteLLM says initial evidence suggests its attacker bypassed the official CI/CD workflows and uploaded straight to PyPI. A team that publishes packages with a stored PyPI token should check whether the OIDC path can replace it.
For Vercel deploys themselves, read what Vercel documents today for each deploy path before planning a migration. If a path still needs a stored token, keep it in a protected environment, limit which workflows can read it, and give it an owner and a rotation date.
Pin the actions as well. The Trivy attacker rewrote existing tags, so a workflow that referenced a tag received the malicious code with no change in its own repository. GitHub’s docs include a guide to locking workflow dependencies, which is the place to start.
What to check this week
Monday. Search every workflow file and build log from March 19 onward for trivy-action, setup-trivy, Trivy v0.69.4, the v0.69.5 and v0.69.6 images, and litellm 1.82.7 or 1.82.8, transitive installs included. Search egress and DNS logs for models.litellm.cloud.
Tuesday. For each matching job, list every secret it could read. Rotate the Vercel tokens, deploy hooks, bypass secrets and cloud keys on that list first. Move off the affected versions to Trivy 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6 and LiteLLM v1.83.0.
Wednesday. Pin third-party actions to commit SHAs and pin Python dependencies in build images, so a moved tag or an unpinned install cannot change what runs.
Thursday and Friday. Move one cloud credential and one publishing token to OIDC. Write down every Vercel token that stays static, with its owner and next rotation date, and review that list monthly.
Sources
- vercel.com/docs/oidc, retrieved 2026-10-26.
- vercel.com/docs/oidc/reference, retrieved 2026-10-26.
- vercel.com/docs/accounts/access-tokens, retrieved 2026-10-26.
- vercel.com/docs/deploy-hooks, retrieved 2026-10-26.
- vercel.com/docs/deployment-protection/methods-to-bypass-deployment-…, retrieved 2026-10-26.
- vercel.com/changelog/turborepo-and-remote-cache-now-support-openid-…, retrieved 2026-10-26.