Author: anonymousmedia_tal70o

This is the first update to the TeamPCP supply chain campaign threat intelligence report, “When the Security Scanner Became the Weapon” (v3.0, March 25, 2026). That report covers the full campaign from the February 28 initial access through the March 24 LiteLLM PyPI compromise. This update covers developments since publication.

The most significant new finding since the report’s publication: the scope of the Checkmarx ast-github-action compromise was substantially larger than publicly reported.

Checkmarx’s official security advisory stated that “all older versions have been permanently deleted” but did not quantify how many tags were affected. This ambiguity allowed the security community to anchor on a single confirmed version — v2.3.28 — as the extent of the compromise. Sysdig’s analysis characterized it as “Checkmarx/ast-github-action/2.3.28: (possibly more).” Even Wiz, which assessed that “it is likely all tags were impacted,” only observed the single tag directly.

An independent security researcher who was working this incident firsthand at a Checkmarx customer has now provided primary evidence that all 91 published tags were overwritten — every version from v0.1-alpha through v2.3.32. The evidence is publicly visible in the GitHub activity log, which shows 91 tag deletions performed during Checkmarx’s remediation between 19:09 and 19:16 UTC on March 23, 2026.

Three of the malicious commits are still visible on GitHub:

Each malicious commit follows an identical pattern: the legitimate Docker-based action.yml was replaced with a composite action that executes a credential-stealing setup.sh before delegating to the legitimate Checkmarx action at pinned SHA 327efb5d. Each commit was individually crafted with a version-appropriate backdated timestamp and fake commit message (e.g., “2.0.30: PR #”). The attacker did not reuse a single malicious commit across multiple tags — they created individual poisoned commits for individual versions.

The impact of this under-reporting is material. Organizations that searched their CI/CD logs only for [email protected] would have missed compromised runs referencing any of the other 90 poisoned tags. The credential stealer executed regardless of which tag version was referenced.

Recommended action: Search your CI/CD workflow logs for ANY reference to checkmarx/ast-github-action that executed between 12:58 and 19:16 UTC on March 23, 2026. If found, treat all secrets accessible to that workflow as compromised and rotate immediately. The only safe version is v2.3.33, released during remediation.

For comparison, the companion kics-github-action received accurate “all 35 tags” reporting from the outset, largely because GitHub Issue #152 was filed publicly with the title “Malware injected in all Git Tags.” No equivalent public issue was filed for ast-github-action.

CISA Adds CVE-2026-33634 to Known Exploited Vulnerabilities Catalog

CISA has added CVE-2026-33634 (CVSS 9.4) to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation. Federal agencies are required to remediate by April 3, 2026. All organizations using Trivy, trivy-action, or setup-trivy should verify they are running safe versions:

• Trivy binary: ≥ v0.69.2
• trivy-action: v0.35.0 (or pin to SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1)
• setup-trivy: v0.2.6 (re-released clean)

PyPI Quarantine Lifted; LiteLLM Freezes All Releases

PyPI lifted its quarantine of the LiteLLM package on March 25 at 20:15 UTC. Malicious versions 1.82.7 and 1.82.8 have been yanked. However, BerriAI has announced they are pausing all new LiteLLM releases pending a complete supply chain security review. Google’s Mandiant has been engaged for forensic analysis. The last known-safe version is v1.82.6.rc.2.

Any installation of LiteLLM v1.82.7 or v1.82.8 should be treated as compromised — rotate all credentials that were present as environment variables, in configuration files, or in Kubernetes secrets on the affected system.

Two community-developed detection tools are now available:

• jthack/litellm-vuln-detector — Scans for malicious .pth files, persistence backdoors (~/.config/sysmon/sysmon.py, systemd user services), exfiltration domains (models.litellm.cloud), and attacker Kubernetes pods (node-setup-* in kube-system).
• Community detection gist — Checks for compromised LiteLLM versions and TeamPCP indicators.

Run these against your CI/CD runners, developer workstations, and any systems where LiteLLM was installed during the March 24 exposure window.

Additional Intelligence

TeamPCP Telegram statement: The threat actor posted to their Telegram channel: “These companies were built to protect your supply chains yet they can’t even protect their own… we’re gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners.” Socket.dev characterizes this as confirmation that TeamPCP is deliberately and systematically targeting security tools as a strategy.

Wiz publishes third analysis: Wiz Research published “Three’s a Crowd: TeamPCP Trojanizes LiteLLM”, confirming LiteLLM is present in 36% of cloud environments they monitor. This is the third Wiz blog post covering the campaign arc (Trivy, KICS, LiteLLM).

RSA Conference timing: Analysts assess that TeamPCP may have deliberately timed the LiteLLM attack to coincide with RSA Conference, when many security teams had reduced staffing. This assessment, reported by CSO Online, is based on temporal correlation and has not been confirmed by the threat actor or forensic evidence.

Parallel campaign — ForceMemo: SecurityWeek reports a separate campaign (“ForceMemo”) using credentials stolen via GlassWorm VS Code extensions to force-push malicious code into approximately 150 GitHub Python repositories. This is NOT TeamPCP but demonstrates the breadth of the current supply chain threat landscape.

Watch Items

• Named victim breach disclosures — expected imminently given active extortion
• Expansion to RubyGems, crates.io, or Maven Central — predicted by Endor Labs but not yet confirmed
• Aqua Security promised additional findings by end of day March 26
• CISA standalone advisory — KEV entry issued, but no dedicated advisory document yet

The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast is scheduled at sans.org/webcasts/when-security-scanner-became-weapon.

The Hacker NewsMar 26, 2026Security Testing / Security Automation

Most teams have security tools in place. Alerts are firing, dashboards look clean, threat intel is flowing in. On the surface, everything feels under control.

But one question usually stays unanswered: Would your defenses actually stop a real attack?

That’s where things get shaky. A control exists, so it’s assumed to work. A detection rule is active, so it’s expected to catch something. But very few teams are consistently testing how all of this holds up when someone is actively trying to break through, step by step.

This is exactly the gap this webinar focuses on.

Exposure-Driven Resilience: Automate Testing to Validate & Improve Your Security Posture is a practical session built around one idea: stop guessing, start proving. Instead of relying on occasional testing or assumptions, it shows how to validate your security posture continuously using real attacker behavior.

The session walks through how to pressure-test both your controls and your processes, how to use threat intelligence to guide what you test, and how to bring this into everyday SOC and incident response workflows without adding unnecessary complexity.

You’ll also hear directly from Jermain Njemanze and Sébastien Miguel, who will break down how this works in practice and walk through a live demonstration.

If you want clear proof that your defenses work, not just signals that they exist, this is worth blocking time for. Save a seat and join the session.

📅 Save Your Spot Today: Register for the Webinar Here.

Ravie LakshmananMar 26, 2026Malware / Mobile Security

The kernel exploit for two security vulnerabilities used in the recently uncovered Apple iOS exploit kit known as Coruna is an updated version of the same exploit that was used in the Operation Triangulation campaign back in 2023, according to new findings from Kaspersky.

“When Coruna was first reported, the public evidence wasn’t sufficient to link its code to Triangulation — shared vulnerabilities alone don’t prove shared authorship,” Boris Larin, principal security researcher at Kaspersky GReAT, told The Hacker News in a statement.

“Coruna is not a patchwork of public exploits; it is a continuously maintained evolution of the original Operation Triangulation framework. The inclusion of checks for recent processors like the M3 and newer iOS builds shows that the original developers have actively expanded this codebase. What began as a precision espionage tool is now deployed indiscriminately.”

Coruna was first documented by Google and iVerify earlier this month as targeting Apple iPhone models running iOS versions between 13.0 and 17.2.1.

Although the use of the kit was first used by a customer of an unnamed surveillance company early last year, it has since been leveraged by a suspected Russia-aligned nation-state actor in watering hole attacks in Ukraine and in a mass exploitation campaign that employed a cluster of fake Chinese gambling and cryptocurrency websites to deliver a data-stealing malware known as PlasmaLoader (aka PLASMAGRID).

The exploit kit contains five full iOS exploit chains and a total of 23 exploits, including CVE-2023-32434 and CVE-2023-38606, both of which were first used as zero-days in Operation Triangulation, a sophisticated campaign targeting iOS devices that involved the exploitation of four vulnerabilities in Apple’s mobile operating system.

The latest findings from Kaspersky indicated the kernel exploits in both Triangulation and Coruna were created by the same author, with Coruna also using four additional kernel exploits. The Russian security vendor said all these exploits are built on the same kernel exploitation framework and share common code.

Specifically, the code includes support for Apple’s A17, M3, M3 Pro, and M3 Max processors, along with checks for iOS 17.2 and iOS version 16.5 beta 4, the latter of which patched all four vulnerabilities exploited as part of Operation Triangulation. The check for iOS 17.2, on the other hand, is meant to take into account the newer exploits, Kaspersky said.

The starting point of the attack is when a user visits a compromised website on Safari, causing a stager to fingerprint the browser and serve the appropriate exploit based on the browser and operating system version. This, in turn, paves the way for the execution of a payload that triggers the kernel exploit.

“After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher,” Kaspersky said. “The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.”

The launcher is the primary orchestrator responsible for initiating the post-exploitation activities, leveraging the kernel exploit to drop and execute the final implant. It also cleans up exploitation artifacts to cover up the forensic trail.

“Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk,” Larin said. “Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks.”

The development comes as a new version of iPhone exploit kit DarkSword has been leaked on GitHub, raising concerns that it could equip more threat actors with advanced capabilities to compromise devices, effectively turning what was once an elite hacking tool into a mass exploitation framework. The release of the new version was first reported by TechCrunch.