🚨 60K Cloud Servers Compromised + The AI Governance Illusion

This week: Critical vulnerabilities under active exploitation, cloud-native worm TeamPCP compromises 60K+ servers across AWS/Azure/GCP, and AI security adoption strategies from Harmonic Security's CTO on building developer-friendly governance that actually works.

Author

Ashish Rajan
February 12, 2026

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The Developer-First AI Governance Dilemma: Building Security Controls That Don't Get Routed Around (continue reading) 

This image was generated by AI. It's still experimental, so it might not be a perfect match!

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter

As ransomware operators actively exploit critical vulnerabilities in email infrastructure and cloud-native threats evolve into self-propagating worms across multi-cloud environments, security teams face a fundamental question: how do we govern rapidly evolving attack surfaces while maintaining the agility that development teams demand?

This week, we examine three critical security stories from the SmarterMail CVE-2026-24423 ransomware campaign to the TeamPCP botnet's multi-cloud rampage and cloud platform abuse for phishing infrastructure. More importantly, we dive deep into a conversation with Bryan Woolgar-O'Neil, CTO and Co-Founder of Harmonic Security, who shares hard-won lessons on implementing AI security governance that developers don't route around. [Listen to the episode]

🚨 This Week’s Mental Security Check

  • 🔥 Ransomware actively exploiting email RCE

  • ☁️ 60,000+ servers wormed across AWS, Azure & GCP

  • 🎣 Phishing kits hosted on trusted cloud domains

  • 🤖 Developers running local MCP servers with production access

Two questions to ask:

1️⃣ Are your Docker/Kubernetes endpoints exposed?
2️⃣ Do you actually know where AI is touching production data?

📰 TL;DR for Busy Readers

  • Patch SmarterMail CVE-2026-24423 immediately

  • Audit exposed Docker APIs & Kubernetes control planes

  • Assume phishing infrastructure now lives on trusted cloud domains

  • 70%+ of AI usage in most orgs is invisible

  • Coaching-based AI governance beats blanket blocking

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1. ☁️ TeamPCP Botnet - The First Real Multi- Cloud-Native Worm Worm Compromises 60,000+ Servers Across AWS, Azure, and GCP

What Happened
Security researchers at Flare published findings on February 9 detailing TeamPCP, a sophisticated cloud-native worm that has successfully compromised over 60,000 servers across all three major cloud platforms AWS, Azure, and Google Cloud Platform. The malware operates through automated exploitation of exposed Docker APIs, misconfigured Kubernetes clusters, and the React2Shell vulnerability, spreading laterally within and across cloud environments. Once established, TeamPCP deploys cryptocurrency miners and functions as command-and-control infrastructure for ransomware operations. The attack chain demonstrates cloud-specific tradecraft, including abuse of cloud metadata services, IAM credential harvesting, and multi-cloud persistence mechanisms.

Why It Matters
TeamPCP represents the maturation of cloud-native attack techniques into wormable, self-propagating threats that treat multi-cloud infrastructure as a unified attack surface. This isn't an opportunistic cryptominer it's a platform for ransomware C2 infrastructure that happens to self-fund through mining while establishing persistent access across your cloud estate.

The multi-cloud dimension is particularly concerning. Organizations that assume cloud security posture management tools provide adequate protection should revisit their assumptions TeamPCP demonstrates how attackers move fluidly between AWS, Azure, and GCP, exploiting the seams between different security tooling and visibility gaps. Your cloud security architecture needs unified detection, shared threat intelligence, and consistent security policies across all cloud platforms.

Immediate actions:

  • Scan for exposed Docker APIs

  • Audit internet-facing Docker and Kubernetes endpoints

  • review IAM policies for least privilege violations,

  • Review Kubernetes API server exposure

  • Enable VPC Flow Logs across environments

  • Monitor metadata service access attempts

  • Threat hunting should focus on abnormal CPU/GPU usage

  • outbound C2 patterns

  • credential access attempts against metadata services.

2. 🎣 Threat Actors Weaponize Azure, Firebase, and AWS for AiTM Phishing Infrastructure

What Happened
Research published by ANY.RUN on February 4 reveals an escalating trend of threat actors abusing legitimate cloud platforms specifically Microsoft Azure, Google Firebase, and AWS to host adversary-in-the-middle (AiTM) phishing kits. These campaigns leverage the trusted domain reputation and SSL certificates of major cloud providers to bypass traditional email security filters and URL reputation systems. The researchers identified widespread deployment of sophisticated phishing frameworks like Tycoon2FA, which specifically targets enterprise users with MFA-enabled accounts by intercepting authentication tokens in real-time. The abuse extends across Azure Static Web Apps, Firebase Hosting, and AWS Amplify.

Why It Matters
When attackers host phishing infrastructure on azure.com, firebaseapp.com, or amazonaws.com subdomains, traditional blocklist-based defenses fail catastrophically. These platforms provide attackers with legitimate SSL certificates, resilient hosting infrastructure, and the same high-availability guarantees your organization relies on for production workloads.

For cloud security leaders, this demands a strategic shift in defensive architecture. Email security posture must evolve beyond domain reputation to incorporate behavioral analysis, real-time link inspection, and user authentication patterns. Cloud platform governance needs to include monitoring for abuse of your own organization's cloud subscriptions if attackers can stand up phishing sites on Microsoft and Google infrastructure, nothing prevents them from doing so within your Azure tenant or GCP project if credentials are compromised.

The AiTM dimension targeting MFA is particularly critical. Organizations that have implemented MFA as a primary security control need to recognize that session token theft bypasses this protection entirely. This reinforces the need for phishing-resistant authentication (FIDO2/WebAuthn), conditional access policies based on device posture and network location, and session lifetime controls that limit token validity windows.

3. AWS IAM Identity Center adds IPv6 (dual-stack endpoints)

What Happened:
AWS announced IPv6 support for IAM Identity Center via new dual-stack endpoints, allowing access over IPv4, IPv6, or dual-stack clients while keeping existing IPv4 endpoints intact. The dual-stack capability applies across access portals, managed applications, and Identity Center flows so authentication can route through IPv6 where available. AWS positioned this as a compatibility and modernization upgrade for orgs operating IPv6 networks and hybrid environments.

Why It Matters (for cloud security leaders)

  • Identity is your control plane’s front door. Introducing IPv6 paths changes the network perimeter assumptions some enterprises still rely on (firewall rules, proxies, allowlists, egress controls), especially where teams accidentally only modeled IPv4 flows.

  • Policy drift risk: If your controls (WAF/proxy, egress filtering, DLP, CASB, SIEM parsing) are IPv4-centric, you can end up with “shadow paths” where identity traffic bypasses expected inspection. This is an availability and security issue: broken routing can cause auth failures; uninspected routing can reduce visibility.

  • Validate that IPv6 is permitted/inspected across enterprise networks where Identity Center traffic originates (office, ZTNA, VDI, managed endpoints).

  • Update firewall/proxy rules and allowlists for the dual-stack domains, and verify your monitoring tooling correctly logs IPv6 addresses (normalization, correlation, geo, alert rules).

  • Run a short change-control test: confirm sign-in flows, SSO to managed apps, and break-glass access still work under dual-stack conditions.

Source: AWS

4. 🚨 SmarterMail CVE-2026-24423: Unauthenticated RCE Under Active Ransomware Exploitation

What Happened
CISA added CVE-2026-24423 to its Known Exploited Vulnerabilities catalog on February 5, 2026, following confirmation that ransomware operators are actively exploiting a critical unauthenticated remote code execution vulnerability in SmarterTools' SmarterMail email server platform. The vulnerability carries a CVSS score of 9.3 and affects versions prior to the emergency patch released in late January. In a striking validation of the threat, SmarterTools itself disclosed on February 9 that it had been breached through this same vulnerability, with attackers gaining access to internal systems. The platform serves over 15 million users globally across enterprise and service provider deployments.

Why It Matters
This incident represents a perfect storm of risk for cloud and hybrid email infrastructure. The vulnerability requires no authentication and enables full system compromise, making it trivially exploitable at scale. Ransomware groups are already operationalizing exploits in the wild; this isn't theoretical. The vendor breach demonstrates that even security-aware organizations struggle with emergency patching timelines, highlighting the window of exposure all SmarterMail operators face.

For cloud security teams, this demands immediate action: inventory verification to identify any SmarterMail instances in on-premises, private cloud, or hybrid deployments; network segmentation review to ensure email infrastructure isn't directly internet-accessible without compensating controls; and incident response preparation given the ransomware context. If you're running SmarterMail, assume a breach until patching is verified.

The CISA KEV listing triggers compliance obligations for federal agencies (21-day patching deadline) but should be treated as a forcing function for private sector cloud environments as well. This reinforces the security maturity gap between legacy on-premises solutions and cloud-native alternatives with automated security updates and vendor-managed infrastructure.

5. WinRAR CVE-2025-8088: “patched, still exploited” across state + cybercrime actors

What Happened
Google reported widespread exploitation of CVE-2025-8088 (patched July 2025) using Windows Alternate Data Streams (ADS) to drop attacker-controlled files into execution/persistence locations (e.g., Startup paths). Despite being an “n-day,” it remains high-impact because patch adoption is uneven.

Why It Matters

  • Endpoint compromise is still the fastest route to cloud session theft and control-plane abuse.

  • This is a governance lesson as much as a vulnerability story: unmanaged “non-core” tools (archivers, plugins) become reliable attacker entry points.

  • Action: force-update WinRAR fleet-wide; detect suspicious archive extraction to autorun locations; tighten conditional access and privilege to reduce downstream cloud blast 

🎯 Cloud Security Topic of the Week:

The Developer-First AI Governance Dilemma

As AI tools become embedded in developer workflows from Claude Code to GitHub Copilot to custom MCP servers security teams face a familiar challenge with unfamiliar characteristics: how do you govern a technology that's being adopted bottom-up by individual contributors, evolves weekly, and produces non-deterministic outputs?

This week's conversation with Bryan Woolgar-O'Neil reveals why traditional security approaches fail in AI adoption and what actually works when developers are your primary threat vector not because they're malicious, but because they're solving business problems faster than your security policies can keep up.

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

  • MCP (Model Context Protocol): A standardization framework released by Anthropic that provides a uniform interface for AI models to interact with various APIs and data sources. Think of it as a plug-and-play system that allows AI agents to connect to GitHub, databases, Jira, or custom internal tools without developers needing to write custom API integrations for each service. Critically, MCP servers can run locally on developer workstations or be hosted centrally, with approximately 70% currently running locally.

  • Shadow AI: Unauthorized or unmonitored AI tool usage within an organization, similar to shadow IT but with higher velocity and risk. This includes personal accounts on ChatGPT, Claude, or Gemini being used for work tasks, unapproved MCP servers accessing production data, or AI coding assistants with unrestricted access to internal repositories.

  • Agent/Agentic Flows: AI systems that can perform multi-step tasks autonomously, making decisions and calling tools or APIs without human intervention at each step. In enterprise contexts, this might mean an AI agent that reads logs, performs root cause analysis, writes code, tests it, and deploys what previously took human developers 3-5 days, now happening in 20 minutes.

  • Small Language Models (SLMs): Specialized, lightweight AI models trained for specific tasks or domains rather than general-purpose use. Unlike large language models (LLMs) that try to handle everything, SLMs can be optimized for faster inference (sub-200ms response times), deployed locally, and fine-tuned for particular use cases like detecting sensitive data patterns or understanding security policy intent.

This week's issue is sponsored by Push Security

Stop browser-based attacks with Push Security

Major breaches are increasingly originating in the browser, where traditional security controls can’t detect them. This is a conscious shift, with both criminal and nation-state actors adopting browser-native TTPs into their standard toolkit.

Push Security brings real-time detection and response into every browser — where today’s work and attacks actually happen. Push gives security teams visibility into modern threats, proactive control over user risk, and powerful telemetry to detect, investigate, and stop attacks fast.

Frictionless deployment. Instant protection.

💡Our Insights from this Practitioner 🔍

Is Developer Friendly AI Security Possible with MCP & Shadow AI (Full Episode here)

The False Sense of AI Security Control

Most organizations believe they have AI usage under control because they've purchased enterprise licenses for ChatGPT, Claude, or Copilot. Bryan Woolgar-O'Neil destroys this illusion quickly: "Even though they can tell that there's a certain amount of traffic going to this website, it is like, what? What does that actually mean to an organization? And I think a lot of them don't know."

The fundamental problem isn't that organizations lack AI tools it's that they lack visibility into what employees are actually doing with them. Traditional security telemetry from firewalls or CASB tools can tell you that users visited claude.ai, but they can't tell you whether those users were:

  • Experimenting with prompt engineering for personal learning

  • Processing production customer data to generate support responses

  • Using personal Gmail accounts instead of enterprise licenses

  • Building MCP servers that connect AI directly to internal databases

This visibility gap creates what Bryan calls "shadow AI" and unlike shadow IT, the blast radius is fundamentally different. "The power that AI can bring to a business... you're doing the same jobs, but the AI's doing it a lot faster, a lot more," he explains. When an engineer can reduce a 3-5 day bug fix process to 20 minutes using Claude Code with MCP access to logs, repositories, and deployment systems, you're not just dealing with unauthorized software you're dealing with unauthorized automation of privileged operations.

The enterprise impact? Organizations that think they're "AI-ready" because they bought licenses are discovering that:

  1. Developers bypass enterprise tools when personal accounts are faster or more capable

  2. Data exfiltration happens at AI velocity, not human cut-and-paste speeds

  3. Personal accounts create data portability risks when employees leave, they take all their prompts and organizational knowledge with them

For security leaders, this means your first priority isn't building AI security policies, it's understanding where AI is actually being used and for what purposes. As Bryan puts it: "Getting that initial visibility. So understand where usage is, and not just at the 'you are using these sites', but with the right level of context and intent."

Why Traditional Security Controls Fail for AI

Traditional approach:

Define policy → Block → Create ticket → Add friction

Developers route around it.

AI evolves weekly.
Outputs are non-deterministic.
Adoption is bottom-up.

You can’t gate this the way you gated cloud migration.

The Shift: Coaching Over Blocking

So what actually works? Harmonic Security's approach, which Bryan's team uses internally before deploying to customers, centers on "coaching in real time rather than blocking everything."

Here's how this manifests in practice:

Scenario: An AI agent is running a 12-minute automated workflow to fix a bug. It needs to pull logs from production, perform root cause analysis, write code, and deploy. At the 10-minute mark, it attempts to send production customer data to a public LLM for analysis.

Traditional Blocking Approach: The security tool kills the entire workflow, the engineer sees "Access Denied," their 10 minutes of progress is lost, and they're furious.

Coaching Approach: The security tool intercepts the data transfer and provides context to the AI agent itself: "This data contains PII and cannot be sent to public LLMs per company policy. Here's what you should do instead: [alternatives]." The AI reads this coaching, adjusts its approach, and completes the task without exposing data.

The key insight is that most AI models will read coaching information and work out a new plan to complete the task without data exposure. You're not blocking the developer's work you're teaching the AI to work within security boundaries.

Bryan extends this to human users as well: "On the browser, we think of the end user similarly... you're trying to coach the end users, the actual employees, to say, well, you're trying to do this, but you're sending this type of data that the organization doesn't want to go into this type of destination."

For example, if an employee tries to paste sensitive data into a free version of a tool when the company has an enterprise license, the coaching system redirects them: "We have an enterprise version of this tool that's approved for this data type use that instead." Or if they're using a public LLM like DeepSeek for data that shouldn't leave the organization: "This model trains on your input data and is hosted in a jurisdiction we don't allow for this data classification. Try [approved alternative]."

The coaching approach works because it assumes positive intent and provides just-in-time education rather than frustration. As Bryan says: "It's almost like a focus on coaching at the point of time of data loss or other types of events that you wanna step in, in the middle of."

The MCP Security Challenge: Local Servers and Data Access

Model Context Protocol (MCP) represents one of the most significant changes in how developers interact with AI, and one of the hardest to secure. Bryan breaks down why:

"Roughly like 70% of MCP servers are local servers. So like... servers that run locally rather than things you connect to."

Why does this matter for security? Three reasons:

  1. Developers can build MCP servers in 3-4 hours without needing infrastructure approval

  2. Local MCP servers inherit the developer's access rights if the engineer can access production databases from their laptop, so can their MCP-enabled AI

  3. No network visibility unlike hosted services that security can monitor via CASB or proxies, local MCP servers operate entirely on the endpoint

This creates a governance nightmare. As Bryan describes from customer conversations: "People were probably seeing it in a similar way to things like third party libraries you might add into code repository. So we wanna have some way of reviewing and risk assessing those and then putting some controls around what is available to be used or not."

The specific risks organizations worry about:

  • Cross-system data flows: An MCP server could "plug into a data store, pull data from that and then push it to the web. And an engineer could have done that previously, but they probably wouldn't 'cause they've got an in-built knowledge of what is acceptable, whereas the AI doesn't have that knowledge."

  • Destructive actions: AI agents with MCP access to Jira, GitHub, or cloud platforms could create projects, repositories, or infrastructure without human oversight

  • Production data access: In permissive organizations where developers have production database access for troubleshooting, MCP servers can now query production data automatically

Bryan's team runs MCP gateway internally: "We've been running it harmonics. So we had our MCP gateway like three or four months before we kind of put it on for customers where we were kind of trying different things out, seeing where we wanted to add in additional controls."

The result? They can allow developers to experiment with MCP locally while maintaining governance: "We don't really want AI to be creating new Jira projects. We don't want it to be creating git repositories because we are not trying to build like a 'go and build my whole website from scratch' prototype thing. It's more like we want you to do this feature, so we want you to exist within our own architecture."

The AI Governance Maturity Model

For CISOs trying to figure out where to start, Bryan offers a practical maturity framework that organizations can progress through:

Level 1 – Basic Logs
You see AI domains being accessed.

Level 2 – Usage Visibility
You understand use cases + intent.

Level 3 – Access Controls
You enforce approved tools and block destructive MCP actions.

Level 4 – Intent-Based Coaching
You intervene intelligently without breaking productivity.

Most organizations are stuck at Level 1.

They think they’re at Level 3.

Developer-First Reality: New Organizational Structures for AI

Perhaps most interesting is how AI adoption is changing organizational structures themselves. Bryan observes: "There's a whole bunch of new job titles and they're not all the same yet."

What he's seeing in the wild:

  • Head of AI Development - Brought into engineering organizations specifically to manage AI tool adoption, typically from engineering and data backgrounds rather than security

  • Evolution of AI Committees - What started as cross-functional committees (CIO, CISO, Legal, Compliance, Privacy) are becoming permanent AI departments with dedicated staff

  • Department-Level AI Specialists - Individual departments hiring AI-focused roles to drive adoption in their specific contexts

This creates interesting dynamics for security teams. As Bryan notes: "Most organizations have a AI committee now... but that committee model's evolved into like we have a department now and it's a small department around AI."

For CISOs, this means AI governance isn't purely a security problem it requires partnership with these new organizational structures. The security team that tries to unilaterally define AI policy will find themselves routed around by departments that have their own AI leadership.

One customer example particularly stands out: their company objective is to "10x every employee via AI." When AI adoption is a board-level business priority at that scale, security teams can't be seen as obstacles they need to enable that 10x productivity while managing risk.

The Future: Small Language Models and Specialized AI

Looking ahead, Bryan sees a shift from general-purpose LLMs toward specialized Small Language Models (SLMs) optimized for specific business functions:

"Organizations will end up having [specialized models] around their different job functions... what will win out is someone will develop their own small language models or constrained models that are great at sales, and they'll be way better than something like OpenAI will be because they're being trained for that specific purpose."

Why does this matter for security? Because each specialized model represents a new attack surface to govern. Harmonic uses SLMs internally because they need sub-200ms response times for real-time coaching something general-purpose LLMs can't deliver consistently.

"We need to get response back within like 200 milliseconds. And we wanna look at intent. So we need to have a model that can understand the context and semantics of what's going in there. And we also want the model to explain to the end user what was wrong."

Building SLMs requires actual ML engineering teams data collection, labeling, feature engineering, training, testing, deployment, and management. "I don't think organizations will build them out of the box," Bryan predicts. Instead, vendors will provide specialized models for different domains: sales AI, coding AI, customer support AI, security AI.

For security teams, this means the "approve these three AI tools" approach won't scale. You'll need frameworks that can govern hundreds of specialized models, each with different capabilities and risk profiles.

Practical Takeaways for Cloud Security Leaders

From Bryan's experience building AI security at Harmonic and deploying it to enterprise customers, here are the actionable lessons:

  • Start with visibility, not policy

  • Assume developers are already using AI

  • Focus on specific pinch points (data exfiltration, destructive ops)

  • Design for coaching, not blocking

  • Treat MCP servers like third-party libraries

  • Expect AI capability to evolve weekly

  • Partner with emerging AI leadership roles

  • Accept that productivity objectives will win — enable safely

Cloud Security Podcast

Question for you? (Reply to this email)

🤔 Are you currently:

A) Blocking AI tools
B) Allowing everything
C) Trying to build decision-point governance

Reply and tell me where you are.

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast