{"id":473,"date":"2026-03-30T02:01:49","date_gmt":"2026-03-30T02:01:49","guid":{"rendered":"https:\/\/quantusintel.group\/osint\/blog\/2026\/03\/30\/our-security-scanner-was-the-hacker-i-spent-last-week-cleaning-up\/"},"modified":"2026-03-30T02:01:49","modified_gmt":"2026-03-30T02:01:49","slug":"our-security-scanner-was-the-hacker-i-spent-last-week-cleaning-up","status":"publish","type":"post","link":"https:\/\/quantusintel.group\/osint\/blog\/2026\/03\/30\/our-security-scanner-was-the-hacker-i-spent-last-week-cleaning-up\/","title":{"rendered":"Our Security Scanner Was the Hacker. I Spent Last Week Cleaning Up."},"content":{"rendered":"
\"A
Photo by Vikram Singh<\/a> on\u00a0Unsplash<\/a><\/figcaption><\/figure>\n

CYBERSECURITY \u00b7 AI \u00b7 SUPPLY\u00a0CHAIN<\/strong><\/h4>\n

This week, the tools your teams use to build and secure AI pipelines were weaponised against you. I know\u200a\u2014\u200aI spent last week rotating secrets because of\u00a0it.<\/em><\/p>\n

Last week I spent three days helping my teams rotate\u00a0secrets.<\/p>\n

Not because we were breached. Not because an attacker found a gap in our architecture. Because a tool we trusted to scan our pipelines for vulnerabilities\u200a\u2014\u200aa tool running inside our CI\/CD with access to our cloud credentials, our SSH keys, our Kubernetes tokens\u200a\u2014\u200ahad been quietly turned into a\u00a0weapon.<\/p>\n

Every secret it touched had to be treated as compromised. Every pipeline it had ever scanned was suspect. We didn\u2019t know exactly what had been taken. We just knew we had to assume the worst and act accordingly.<\/p>\n

That\u2019s the incident response reality that doesn\u2019t make the CVE writeups. The scramble. The inventory. The 3AM Teams thread where someone asks \u201cdo we know which version we were running on March\u00a019th?\u201d<\/p>\n

This is what it looks like when your security stack becomes the attack\u00a0surface.<\/strong><\/p>\n

The Week the AI Security Stack Collapsed<\/strong><\/h4>\n

Most coverage of what happened this week reads like a CVE changelog. I want to tell it differently\u200a\u2014\u200aas a timeline, because the shape of this attack is what makes it extraordinary.<\/p>\n

March 19, 2026.<\/strong> A threat actor group called TeamPCP compromised Trivy\u200a\u2014\u200athe most widely used open-source vulnerability scanner in the cloud-native ecosystem. They didn\u2019t find a zero-day in Trivy\u2019s code. They compromised credentials from a prior, incompletely remediated security incident and used them to do something far more surgical.<\/p>\n

They force-pushed malicious commits to 76 out of 77 version tags in the aquasecurity\/trivy-action GitHub repository and all 7 tags in aquasecurity\/setup-trivy. The legitimate version labels still appeared in every pipeline. The metadata showed no visible changes. But underneath, the payload was\u00a0running.<\/p>\n

Pipelines appeared to work normally while the credential stealer ran silently underneath.<\/em><\/p><\/blockquote>\n

Within hours:<\/strong> SSH keys stolen. Cloud access tokens harvested. Kubernetes secrets exfiltrated. Everything the pipeline touched\u200a\u2014\u200agone.<\/p>\n

Day 2.<\/strong> Stolen npm tokens fed a self-propagating worm that infected 66+ npm packages across multiple organizations.<\/p>\n

Day 4.<\/strong> Malicious Docker images were pushed. 44 Aqua Security repositories defaced.<\/p>\n

Day 5.<\/strong> Checkmarx KICS and AST GitHub Actions hijacked. Malicious VS Code extensions published.<\/p>\n

Day 6.<\/strong> LiteLLM\u200a\u2014\u200athe AI API gateway present in 36% of all cloud environments\u200a\u2014\u200awas compromised on PyPI. Using credentials stolen from a Trivy scan. One dependency. One chain reaction. Five supply chain ecosystems in six\u00a0days.<\/p>\n

One stolen token became five compromised ecosystems in less than a\u00a0week.<\/strong><\/p>\n

The Trivy Betrayal\u200a\u2014\u200aWhen the Scanner Becomes the\u00a0Weapon<\/strong><\/h4>\n

Here\u2019s what makes this attack so architecturally significant: Trivy isn\u2019t a random developer tool. It\u2019s a security tool. It\u2019s the thing you deploy specifically to make your pipelines safer.<\/p>\n

And that\u2019s precisely what made it valuable to\u00a0TeamPCP.<\/p>\n

Trivy runs in thousands of CI\/CD pipelines as a GitHub Action on every PR, every merge, every deployment. It runs with elevated access to pipeline secrets by design\u200a\u2014\u200abecause it needs to scan containers, check images, analyze infrastructure code. Compromise Trivy, and you don\u2019t just get code. You get everything the pipeline is authorised to\u00a0touch.<\/p>\n

The attackers chose their target wisely. Security tools run with broad access because that\u2019s how they function. Compromising one hands you every credential that tool was trusted to\u00a0touch.<\/em><\/p><\/blockquote>\n

What my teams experienced last week was the operational reality of that trust model failing. We had to answer questions that most organizations have never thought to ask: Which workflows ran trivy-action? Which version? Between what timestamps? What secrets were in scope for those\u00a0runners?<\/p>\n

Most teams couldn\u2019t answer those questions quickly. Some couldn\u2019t answer them at\u00a0all.<\/p>\n

The attack payload was injected into entrypoint.sh, executing before the legitimate Trivy scan began. From a pipeline operator\u2019s perspective, everything looked normal. The scan ran. The report came back. Nobody knew a credential stealer had already completed its\u00a0work.<\/p>\n

The most dangerous attack is the one that looks like business as\u00a0usual.<\/strong><\/p>\n

The Chain Reaction\u200a\u2014\u200aHow Trivy Became\u00a0LiteLLM<\/strong><\/h4>\n

If the Trivy compromise was a targeted strike, what followed was a\u00a0cascade.<\/p>\n

BerriAI\u200a\u2014\u200athe company behind LiteLLM\u200a\u2014\u200auses Trivy in its CI\/CD pipeline for security scanning. When TeamPCP\u2019s poisoned trivy-action executed inside that pipeline, it harvested the PyPI publishing credentials. From there, the attackers published malicious versions 1.82.7 and 1.82.8 of LiteLLM directly to PyPI, bypassing the normal release process entirely.<\/p>\n

LiteLLM is not a niche tool. It has over 40,000 GitHub stars, approximately 95 million monthly downloads, and is present in 36% of cloud environments monitored by Wiz Research. Organizations use it as a unified gateway to route requests to over 100 LLM providers\u200a\u2014\u200aOpenAI, Anthropic, Azure OpenAI, Google Vertex AI, AWS Bedrock. It manages API keys. It tracks usage costs. It holds the keys to your entire AI infrastructure.<\/p>\n

TeamPCP did not need to attack LiteLLM directly. They compromised Trivy, a vulnerability scanner running inside LiteLLM\u2019s CI pipeline without version pinning. That single unmanaged dependency handed over the PyPI publishing credentials, and from there the attacker backdoored a library that serves 95 million downloads per\u00a0month.<\/em><\/p><\/blockquote>\n

The malware itself was elegant in a way that makes you uncomfortable. It used a Python\u00a0.pth file\u200a\u2014\u200aa mechanism that auto-executes on any Python interpreter startup without requiring an import statement. Every python command. Every pip install. Every pytest run. Silent credential theft, running in the background, every single\u00a0time.<\/p>\n

You didn\u2019t have to run LiteLLM. You just had to run Python in an environment where it was installed.<\/strong><\/p>\n

Approximately 300GB of data was exfiltrated from around 500,000 infected machines. TeamPCP is now reportedly working through those credentials and collaborating with the LAPSUS$ extortion group to target multi-billion-dollar companies. The incident is not\u00a0over.<\/p>\n

The Second Front\u200a\u2014\u200aLangflow and the 20-Hour\u00a0Window<\/strong><\/h4>\n

While the Trivy cascade was unfolding, a separate but structurally identical story was playing out in the AI builder\u00a0space.<\/p>\n

On March 17, 2026, a critical vulnerability was disclosed in Langflow\u200a\u2014\u200athe open-source visual platform with 145,000+ GitHub stars used to build AI agents and RAG pipelines. CVE-2026\u201333017 allows unauthenticated remote code execution via a single HTTP POST request. No credentials required. No exploit chain. One\u00a0request.<\/p>\n

Twenty hours after the advisory was published, attackers were already scanning the internet for vulnerable instances. No public proof-of-concept code existed at the time. They built working exploits directly from the advisory description.<\/p>\n

Threat actors are monitoring the same advisory feeds that defenders use, and they are building exploits faster than most organisations can assess, test, and deploy\u00a0patches.<\/em><\/p><\/blockquote>\n

The median time-to-exploit has collapsed from 771 days in 2018 to just hours in 2024. The median time for organizations to deploy patches is still approximately 20 days. That gap\u200a\u2014\u200a20 hours vs. 20 days\u200a\u2014\u200ais not a patching problem. It\u2019s a structural assumption problem.<\/p>\n

Langflow instances are configured with API keys for OpenAI, Anthropic, AWS, and database connections. A single compromised instance gives an attacker lateral access to cloud accounts, AI service budgets, and data stores simultaneously. And most of those instances were deployed by data science teams who never filed a security review\u00a0request.<\/p>\n

The AI tooling your organization is deploying outside of standard security review is carrying your crown jewel credentials. Attackers know this. Most security teams\u00a0don\u2019t.<\/strong><\/p>\n

\"Three
Photo by David Schultz<\/a> on\u00a0Unsplash<\/a><\/figcaption><\/figure>\n

The Pattern No One Is Talking\u00a0About<\/strong><\/h4>\n

Step back from the individual CVEs and look at what TeamPCP actually targeted this\u00a0week:<\/p>\n

Trivy\u200a\u2014\u200aa vulnerability scanner. Checkmarx KICS\u200a\u2014\u200aan infrastructure-as-code scanner. LiteLLM\u200a\u2014\u200aan AI API gateway. Langflow\u200a\u2014\u200aan AI agent\u00a0builder.<\/p>\n

These are not random targets. They are the tools organizations deploy to improve their security posture and build AI capabilities. The most security-conscious organizations\u200a\u2014\u200athe ones scanning every build, every PR, every deployment\u200a\u2014\u200ahad the greatest Trivy exposure.<\/p>\n

The organisations doing the right things had the most to lose. That\u2019s not a coincidence. That\u2019s the design of the\u00a0attack.<\/em><\/p><\/blockquote>\n

As a cybersecurity architect I\u2019ve spent 13 years thinking about trust models. What this week exposed is a trust model failure that most organisations have never explicitly addressed: we grant our security and AI tools elevated access by design, and we never model what happens when those tools themselves are compromised.<\/p>\n

I\u2019ve written about the automation bias trap\u200a\u2014\u200athe tendency to trust tool output over professional judgment. This is that trap operating at infrastructure level. The tool becomes the assumption. The assumption becomes the blind spot. The blind spot becomes the\u00a0breach.<\/p>\n

The same mental pattern that makes an engineer say \u201cwe have a WAF so our APIs are protected\u201d now shows up as \u201cwe use Trivy so our pipelines are scanned.\u201d The tool is the control. The control is trusted implicitly. Nobody asks what happens if the control itself\u00a0fails.<\/p>\n

You cannot build a security model that doesn\u2019t account for the security of the security\u00a0tools.<\/strong><\/p>\n

What You Need to Do Right\u00a0Now<\/strong><\/h4>\n

I\u2019m not going to give you a 47-point checklist. Here\u2019s what actually matters, in priority\u00a0order.<\/p>\n

    \n
  1. Check your Trivy version immediately.<\/strong> Safe versions: Trivy binary v0.69.3 or earlier, trivy-action v0.35.0 (pinned to commit 57a97c7), setup-trivy v0.2.6 (commit 3fb12ec). If you ran v0.69.4 at any point during March 19\u201320, treat all secrets accessible to those workflows as compromised.<\/li>\n
  2. Rotate everything those pipelines touched.<\/strong> GitHub tokens, cloud provider credentials, registry tokens, SSH keys, database passwords. Do not wait to confirm exploitation. The operational cost of unnecessary rotation is significantly lower than the cost of assuming you\u2019re clean when you\u2019re\u00a0not.<\/li>\n
  3. Look for tpcp-docs repositories.<\/strong> If your GitHub organization has a repository named tpcp-docs that you didn\u2019t create, the fallback exfiltration mechanism was triggered and secrets were successfully stolen. This is your\u00a0canary.<\/li>\n
  4. Audit your AI tooling inventory.<\/strong> Langflow, LiteLLM, n8n, and similar platforms. Find out who deployed them, what credentials they hold, whether they\u2019re internet-exposed, and whether they went through any security review. In many organizations, the answer to all of those questions will be uncomfortable.<\/li>\n
  5. Pin your GitHub Actions to full commit SHAs.<\/strong> Mutable version tags can be force-pushed. This attack proved it at scale. A tag that said v0.34.0 last week does not guarantee it points to the same code today. Immutability is the only guarantee.<\/li>\n<\/ol>\n

    The Architecture Problem Behind All of\u00a0This<\/strong><\/h4>\n

    Three days into last week\u2019s incident response, one of my engineers asked a question that stuck with me: \u201cHow do we model the risk of the tools we use to manage\u00a0risk?\u201d<\/em><\/p>\n

    It\u2019s not a question most security frameworks ask. Threat models focus on the systems you\u2019re protecting. Vulnerability management programs focus on the software you deploy for your users. Nobody formally models the attack surface of the security toolchain itself.<\/p>\n

    TeamPCP found that gap and walked straight through it. They didn\u2019t need a zero-day in your application. They needed a zero-day in your trust model. And your trust model said: the scanner is safe, because the scanner is the thing that finds unsafe\u00a0things.<\/p>\n

    The events of this week aren\u2019t an anomaly. They\u2019re a preview. As AI tooling proliferates\u200a\u2014\u200aas every organization deploys agents, pipelines, and gateways holding credentials to everything\u200a\u2014\u200athe attack surface doesn\u2019t just grow. It compounds. Every new tool that touches sensitive secrets is a new potential pivot\u00a0point.<\/p>\n

    I spent three days rotating secrets last week. I\u2019d do it again in a heartbeat if it meant my teams were clean. But the harder work\u200a\u2014\u200athe work that prevents next time\u200a\u2014\u200ais building an architecture where the security of the security tools is treated with the same rigor as the security of everything else.<\/p>\n

    The most dangerous position in security isn\u2019t being attacked. It\u2019s trusting that the thing protecting you is still on your\u00a0side.<\/strong><\/p>\n

    I write weekly about cybersecurity, AI, and the human psychology that connects them. If this made you check your pipeline inventory, follow me here on <\/em>Medium<\/em><\/a> and connect with me on <\/em>LinkedIn<\/em><\/a>.<\/em><\/p>\n

    Did your organization use Trivy or LiteLLM? What did your incident response look like? I\u2019d love to hear in the comments.<\/strong><\/p>\n

    \"\"<\/p>\n

    \n

    Our Security Scanner Was the Hacker. I Spent Last Week Cleaning Up.<\/a> was originally published in OSINT Team<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

    Photo by Vikram Singh on\u00a0Unsplash CYBERSECURITY \u00b7 AI \u00b7 SUPPLY\u00a0CHAIN This week, the tools your teams use to build and secure AI pipelines were weaponised against you. I know\u200a\u2014\u200aI spent last week rotating secrets because of\u00a0it. Last week I spent three days helping my teams rotate\u00a0secrets. Not because we were breached. Not because an attacker … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-473","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/posts\/473","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/comments?post=473"}],"version-history":[{"count":0,"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/posts\/473\/revisions"}],"wp:attachment":[{"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/media?parent=473"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/categories?post=473"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/quantusintel.group\/osint\/wp-json\/wp\/v2\/tags?post=473"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}