Security researchers at Oligo Security have uncovered a threat actor, TeamPCP, that has been active since 2020. Initially targeting infrastructure like Redis, Docker, and Kubernetes, they've now shifted to supply chain compromises through GitHub Actions token theft and React Server Components exploitation.
This is a real threat. If your team uses exposed Redis instances, AI infrastructure, or GitHub Actions in your CI/CD pipeline, you need to understand what happened and where your controls might have similar vulnerabilities.
What Happened
Since 2020, TeamPCP has exploited internet-facing infrastructure. Their early campaigns focused on misconfigured Redis servers, Docker APIs, and Kubernetes clusters for cryptocurrency mining and data exfiltration.
In 2025, they evolved. Two campaigns stand out:
ShadowRay 2.0 targeted AI infrastructure. While specifics aren't public, the pattern is familiar: find exposed services, exploit weak authentication, and establish persistence.
TA-NATALSTATUS targeted Redis servers with more sophisticated techniques than in their 2020 campaigns, refining their tools and expanding targets.
The biggest shift was their move to supply chain attacks. They exploited security flaws in React Server Components and Next.js to extract credentials and used GitHub Actions to steal tokens and inject malicious code into build pipelines.
Timeline
2020-2024: TeamPCP attacks infrastructure like Redis, Docker, and Kubernetes for cryptocurrency mining and data exfiltration, exploiting exposed services and weak authentication.
Early 2025: ShadowRay 2.0 targets AI infrastructure. TA-NATALSTATUS improves techniques against Redis servers.
Mid-2025: The group pivots to supply chain attacks, exploiting React Server Components and Next.js vulnerabilities for credential theft and targeting GitHub Actions for token extraction and pipeline compromise.
Current: Oligo Security publishes analysis linking all campaigns to TeamPCP, revealing five years of continuous operations.
Which Controls Failed
Network Segmentation: Redis, Docker, and Kubernetes services were exposed to the internet. These should be behind network boundaries with strict access controls.
Authentication: Attacks succeeded due to lack of proper authentication or use of default credentials. Docker APIs without TLS, Redis instances with no password, and Kubernetes clusters with overly permissive RBAC were common issues.
Dependency Management: React Server Components and Next.js exploits worked because vulnerable versions remained in production. There was no automated dependency scanning or rapid patching process.
Secrets Management: GitHub Actions tokens were accessible to attackers, indicating secrets were hardcoded, stored in environment variables without proper scope restrictions, or workflows had excessive permissions.
Build Pipeline Security: The supply chain compromise succeeded because CI/CD pipelines lacked integrity checks. There was no verification of workflow sources, no attestation of build artifacts, and no monitoring for unauthorized modifications.
What Standards Require
PCI DSS v4.0.1 Requirement 1.4.2 requires restricting inbound traffic to only what's necessary. Redis instances, Docker APIs, and Kubernetes control planes should never be internet-accessible unless there's a documented business justification and compensating controls.
NIST CSF v2.0 PR.DS-6 requires integrity checking mechanisms for software and firmware, including dependencies. Automated scanning should catch vulnerable versions of React, Next.js, or any other component before they hit production.
ISO 27001 Annex A.8.30 covers software development security, requiring protection of development and build environments. GitHub Actions tokens are part of that environment. Requirement A.5.15 covers access control for those credentials.
SOC 2 Type II CC6.1 addresses logical and physical access controls. If your CI/CD pipeline is in scope, you need to demonstrate that tokens and secrets have appropriate restrictions, that access is reviewed, and that changes to build processes are monitored.
OWASP ASVS v4.0.3 Section 14.2 covers build and deploy security. Level 2 requires that build pipelines verify the integrity of dependencies (14.2.1) and that secrets are not stored in source code or build scripts (14.2.5).
Lessons and Action Items
Audit your exposed services today. Run a Shodan or Censys search for your organization's IP ranges. Look for Redis, Docker, Kubernetes, or any other infrastructure service responding to the internet. If you find any, you have a critical gap. Close it before moving to the next item.
Implement network segmentation for all infrastructure services. Your Redis caches, container orchestration, and database management tools should be behind VPNs or zero-trust access controls. Document the business justification for any exception and implement compensating controls.
Automate dependency scanning in your CI/CD pipeline. Use tools like Dependabot, Renovate, or Snyk. Configure them to fail builds when they detect vulnerabilities with available patches. Set a policy: critical vulnerabilities get patched within 48 hours, high-severity within one week.
Rotate all GitHub Actions tokens and implement short-lived credentials. Use GitHub's OIDC provider to generate tokens with limited scope and duration. Never store long-lived tokens in repository secrets. Review your Actions workflows for excessive permissions and apply least privilege.
Add integrity verification to your build pipeline. Implement Sigstore for signing artifacts, use SLSA framework principles for provenance, and verify checksums for all external dependencies. This won't prevent all supply chain attacks, but it makes them significantly harder.
Monitor your build environments. Set up alerts for unauthorized changes to GitHub Actions workflows, new secrets added to repositories, or modifications to build scripts. These should trigger immediate investigation.
TeamPCP operated for five years because the controls above were missing or incomplete. You don't need perfect security to avoid being their next target. You need to make your infrastructure harder to exploit than the next organization's. Start with the exposed services audit. Do it this week.
