Weekly Security Roundup: MCP auth, infostealers, supply chain

by TechHub

Welcome to this week's Weekly Security Roundup, where the thread tying most stories together is control: tighter authorization for agent tooling, stronger defaults in developer ecosystems, and faster containment when accounts and tokens get hit. On the threat side, Microsoft detailed phishing-to-implant activity delivering a persistent Node.js payload, plus infostealer ecosystems (StealC and Amadey) built and sold as services, and a DART case study showing how two separate attackers can overlap in the same environment. On the defense side, MCP security moved from connectivity to governance with enterprise-managed authorization in VS Code, APIM-fronted authorization patterns, hardened App Service hosting guidance, and new warnings about persistent AI memory as an injection surface. The roundup closes with practical supply chain and identity hardening updates across npm, Dependabot, GitHub Enterprise incident response controls, Azure DevOps workload identity federation, and platform-level protections like Secure Boot readiness, confidential computing, and Rowhammer defenses.

This Week's Overview

Threat intel: phishing-to-implant campaigns and infostealer ecosystems

Photo ZIP phishing delivers a persistent Node.js implant

Microsoft Defender Security Research Team reported a campaign aimed at hospitality organizations that starts with photo-themed ZIP attachments and fake image LNK files, a continuation of last week's theme that familiar lures and trusted distribution habits still reliably turn into full endpoint compromise. When opened, the LNK launches obfuscated PowerShell (including BigInt-based obfuscation) that drops a Node.js implant and sets up persistence using dual HKCU Run and RunOnce keys.

For defenders, this is a reminder that “harmless” file lures still reliably deliver full remote access, and that persistence can be as simple as user-level registry keys that survive reboots. The post includes Defender detections, IOCs, and Microsoft Defender XDR hunting queries, which makes it immediately actionable for teams that can pivot from email telemetry to endpoint and identity signals.

StealC and Amadey: loaders, services, and disruption actions

A separate Microsoft Threat Intelligence write-up dug into the StealC infostealer and the Amadey loader, focusing on how initial access and delivery are packaged as “cybercrime services” that other actors can rent, building on last week's AI-themed phishing coverage by showing the next step after a lure succeeds: credential theft designed for resale and follow-on access. The analysis covers C2 behavior, credential theft techniques, and persistence patterns, then ties the findings to concrete mitigations using Microsoft Defender for Endpoint and Microsoft Defender XDR.

The post also notes a disruption action taken on June 24, 2026 against related infrastructure, plus Security Copilot scenarios for investigation and automation. For incident responders, the key takeaway is that infostealer incidents are rarely “one-and-done”; they are designed to feed downstream fraud and follow-on access, so rapid token/session invalidation and endpoint cleanup matter as much as initial detection.

One intrusion, two attackers: parallel activity in the same environment

Microsoft Incident Response (DART) shared a case study where two unrelated threat actors operated at the same time inside the same victim environment, creating overlapping artifacts that complicated attribution and containment, which complements last week's point that modern intrusions often blend multiple playbooks and abuse trusted tooling in ways that make “one incident” look deceptively linear. The investigation highlights techniques like remote access tooling and DLL sideloading, and shows how blended tradecraft can look like “one actor changing tactics” when it is actually multiple operators.

The defensive message is operational: centralize telemetry and correlate across identity, endpoint, and network sources so you can separate parallel playbooks, not just match IOCs. DART also reinforces the basics that reduce blast radius in almost every ransomware investigation: patching discipline, stronger identity controls, and visibility that supports timeline reconstruction.

Agent and MCP security: enterprise authorization, hardened hosting, and secure “memory”

This week had a clear theme: as MCP (Model Context Protocol) adoption grows, security work is shifting from “how do I connect tools?” to “how do I control access, audit it, and reduce new agent attack surfaces?” The updates span protocol authorization (EMA), deployment architectures (App Service + APIM), and emerging problems like persistent agent memory.

MCP Enterprise-Managed Authorization (EMA) lands in VS Code

A deep-dive on MCP's Enterprise-Managed Authorization (EMA) explains how VS Code 1.123 enables enterprise-managed MCP authentication through identity providers like Microsoft Entra ID, Okta, and Auth0, extending last week's MCP governance thread (safe tool exposure and scanning) into the access-control and audit model enterprises need for broad rollouts. The big shift is moving from per-server OAuth consent flows (hard to govern at scale) to IdP-driven policy and auditability, which is what security teams typically require before allowing broad internal usage.

The post also calls out how this complements GitHub Copilot controls, such as registry allowlists in GitHub Enterprise, so organizations can manage both “who can authenticate” and “which servers/tools are allowed.” If you are rolling MCP into developer environments, EMA reduces friction while making it easier to align with centralized access reviews and logging.

Securing MCP servers with Azure API Management and Entra ID

A practical guide walks through using Azure API Management (APIM) as a security boundary for MCP servers, from basic Entra ID token validation to more advanced controls, picking up where last week's App Service built-in MCP preview left off by showing how to put consistent authZ and tool-level blocking in front of those exposed operations. It covers interactive OAuth sign-in using Protected Resource Metadata (RFC 9728), app-role based authorization, passthrough patterns for external MCP servers (including GitHub), and gateway-side blocking of specific tool invocations.

The gateway approach is useful when you need consistent enforcement across many MCP servers, especially when teams want to ship tools quickly. APIM policy becomes the place to standardize requirements like “this tool requires this role” or “block high-risk tool calls,” without having to re-implement controls in each MCP server.

Hardened MCP hosting on App Service (and why OAuth adoption is low)

Another Azure-focused reference architecture argues that many MCP servers are being deployed without OAuth and uses recent MCP-related CVEs as motivation for a hardened baseline, reinforcing last week's point that MCP expands the “tool surface area” and needs platform-managed auth to avoid becoming an ungoverned execution plane. The proposed setup uses Azure App Service Authentication (Easy Auth) with Entra ID plus Protected Resource Metadata (PRM), then layers in managed identity, Key Vault references, private networking/private endpoints, API Management in front of the server, and Azure Monitor alerts.

For platform teams, this is a useful checklist for making “secure by default” the easy path when internal teams experiment with agents. It also emphasizes a practical point: if you cannot reliably enforce authN/authZ at the protocol edge, your tool surface becomes a new remote execution plane, especially once agents can invoke tools autonomously.

Azure Functions MCP extension adds Entra ID auth and OBO samples

The Azure Functions MCP extension update includes resource and prompt triggers, MCP Apps for interactive UI, structured and rich content responses, and built-in MCP authentication using Microsoft Entra ID, continuing last week's “agent ops” direction by making identity-first tool calls and repeatable authorization patterns easier to ship in common serverless stacks. It also calls out On-Behalf-Of (OBO) flow samples, which matter when your function needs to call downstream APIs under the user's identity rather than using a broad service credential.

If you are building agent tooling on Functions, the auth pieces are the security critical path because they determine whether tool calls are attributable to a user and whether least privilege is possible. The roadmap notes planned support for streaming output and pagination, which will be relevant for avoiding oversized responses and for building safer “bounded” tools.

MCP for Beginners curriculum: spec alignment and security fixes

Microsoft's MCP for Beginners curriculum was updated to align with the 2025-11-25 MCP spec and now includes validated TypeScript and Python SDK samples, following last week's emphasis that MCP examples can become production templates so security fixes in learning materials matter more than they sound. It also received a security pass that included dependency audits and a command-injection fix, which is the kind of “boring but essential” work that keeps sample code from becoming production anti-patterns.

If your team learns MCP by copying examples, treat the curriculum version and SDK sample provenance as part of your security review. The post is a good reminder to pin dependencies and re-audit scaffolding projects, since agent tooling often runs with access to sensitive data and credentials.

Guarding AI memory: persistent state becomes a new injection surface

Microsoft outlined why persistent “AI memory” increases risk for agents, including delayed, cross-session attacks like adversarial memory poisoning and delayed tool invocation, building on last week's agent governance and eval focus by highlighting that even “state” (not just prompts/tools) needs policy, validation, and audit trails. The write-up describes protections in Microsoft 365 Copilot across memory creation, storage, and observability, including write-time sanitization and compliance controls.

For security teams, the most actionable detail is observability: audit events like MemoryUpdated can be used in Microsoft Defender Advanced Hunting and Microsoft Sentinel to detect suspicious memory writes or unexpected changes. If you are building your own agent memory features, this is a strong argument for treating memory as untrusted input, applying validation/sanitization at write time, and logging changes as first-class security events.

Software supply chain and developer platform controls

npm adds protective friction for high-impact accounts

npm introduced preventive account protection for “high-impact” accounts: after sensitive changes like email updates or using 2FA recovery codes, the account enters a 72-hour read-only window, which fits the same “tighten defaults and slow attackers down” pattern we highlighted last week across CI/CD gates and credential sprawl reduction. During that period, actions like publishing packages and managing tokens are restricted, which reduces the chance that an account takeover immediately turns into a supply chain incident.

For maintainers, this is a trade-off that favors ecosystem safety over immediate operational flexibility, and it is worth planning for when rotating credentials or recovering accounts. For organizations that depend on key packages, it is another reason to diversify critical dependencies and monitor maintainer account events where possible.

npm 12 tightens install-time script execution by default

DevClass covered npm 12's upcoming breaking changes that disable automatic install-time lifecycle scripts by default and tighten remote dependency fetching, extending last week's “secure-by-default” throughline from platform controls into the package manager behaviors that make supply chain attacks cheap to execute. Lifecycle scripts have been a long-running supply chain risk because they execute arbitrary code during installation, so turning them off by default reduces exposure to typosquats and compromised dependencies.

Teams will need migration plans, especially for projects that legitimately rely on install scripts for native builds or postinstall steps. The article notes allowlist-based approaches and that npm 11.x users can start preparing now through .npmrc settings, which is useful if you want to measure impact before taking the npm 12 jump.

Dependabot changes: fewer PATs for registries, and Python 3.9 is out

Dependabot can now access private GitHub-hosted registries using the built-in GITHUB_TOKEN (with packages:read) as long as the package grants the repository Actions access, which directly continues last week's push to reduce PAT usage (including for agentic workflows) and shrink long-lived credential sprawl in CI. This reduces the need to provision and rotate PATs purely for dependency updates, which is a meaningful improvement for least privilege and secret sprawl in CI.

At the same time, Dependabot dropped Python 3.9 support because it is end-of-life, and GitHub warns that repositories still on 3.9 may stop receiving dependency update pull requests. If you have update coverage requirements, treat the runtime upgrade as a security dependency, not just a language maintenance task.

More control and observability in GitHub Enterprise and Advanced Security

GitHub added “break-glass” incident response capabilities for enterprises, including bulk revocation of SSO authorizations and deletion of credentials (PATs, SSH keys, OAuth tokens), plus a self-service Settings → Credentials experience for members, which pairs naturally with last week's theme of tightening CI trust and reducing token exposure by speeding up containment when something still slips through. It also introduced org-level programmatic support through REST APIs and improved auditing with logs and email notifications, which helps reduce time-to-containment when a token leak is suspected.

On the AppSec side, GitHub shipped a public preview REST API for fetching GitHub Code Quality (CodeQL) findings at the repository level, supporting filtering, pagination, and retrieval by finding number. GitHub secret scanning also added extended metadata for Replicate secrets (replicate_api_token), giving developers more context in alerts and making triage less guessy.

Locking down plugin sources for VS Code and Copilot CLI

GitHub Copilot enterprise-managed settings added strictKnownMarketplaces (public preview), allowing organizations to restrict which marketplaces VS Code and GitHub Copilot CLI can install plugins from via enterprise-managed settings.json, extending last week's agent tooling story (Copilot CLI workflows and MCP controls) into a practical supply-chain control for the developer environment itself. This is a practical supply chain control because plugins are executable code and a common entry point for credential theft and data exfiltration.

For admins, the value is centralized enforcement: teams can keep VS Code extensible while reducing exposure to untrusted marketplaces. Pair it with allowlists for MCP registries and tighter token scopes to make “developer customization” less risky in regulated environments.

Identity and workload federation: Entra issuer migration and safer automation

Azure DevOps OIDC issuer retirement for workload identity federation

Microsoft announced the deprecation of the Azure DevOps OIDC issuer (https://vstoken.dev.azure.com) for Workload Identity Federation (WIF) service connections, with retirement scheduled for July 1, 2027, continuing last week's enterprise identity hardening theme (passkeys, IP restrictions, and federated patterns) by pushing more automation onto standardized Entra-backed identity. The guidance is to migrate service connections to the Microsoft Entra issuer, which standardizes identity and aligns better with enterprise policy controls.

Even though the deadline is a year out, identity plumbing changes tend to surface during incident response or pipeline outages, so it is worth scheduling early. Treat this as part of your “credentials to federation” roadmap, especially if you are trying to remove long-lived secrets from CI/CD.

Azure Developer CLI (azd) continues tightening auth and pipeline scenarios

Azure Developer CLI (azd) releases 1.24.3 through 1.26.0 include new azd tool and azd exec commands, plus fixes across authentication, concurrency, and CI/pipeline workflows, aligning with last week's “reduce operational friction so secure paths get used” message around built-in tokens and centralized logging. While not purely “security features,” these changes matter because broken auth flows and inconsistent environment handling often push teams back toward ad-hoc secrets and manual steps.

If you rely on GitHub OIDC or other federated approaches, keep an eye on azd behavior in automation and provisioning, since safer defaults and fewer edge-case failures reduce pressure to introduce PATs or shared service principals. The release notes format also makes it easier to spot changes that might impact locked-down build agents.

Platform and infrastructure hardening: Secure Boot, TEEs, and Rowhammer defenses

Linux Secure Boot CA expiration in 2026: the real failure mode to test

Microsoft published practical guidance on the June 2026 expiration of the Microsoft UEFI CA 2011 and why that date does not instantly brick Linux Secure Boot, which complements last week's hybrid hardening thread (like LAPS for Arc) by focusing on the firmware and boot trust chain that underpins endpoint policy enforcement. The problem shows up when devices do not trust the Microsoft UEFI CA 2023 and later receive a shim that is signed only by the 2023 CA, which can prevent boot in Secure Boot mode.

The post includes concrete fleet checks and the right vendor questions, including validating firmware trust databases and shim signatures, with tools like mokutil and fwupd. For IT and platform teams, the message is to test updates on representative hardware now, because the failure only appears when new shims roll out and older firmware trust stores lag behind.

Azure Confidential Computing: sovereignty, attestation, and confidential AI

Azure Confidential Computing updates focused on how hardware-rooted trusted execution environments (TEEs) and attestation support regulated workloads and digital sovereignty requirements, echoing last week's emphasis on enforceable guardrails by shifting some controls into hardware-backed boundaries with verifiable measurement. The post references confidential VMs using AMD SEV-SNP and Intel TDX, plus operational capabilities like confidential live migration and trust controls for protecting keys (including Azure Integrated HSM).

For teams adopting confidential AI inferencing, the practical question is how you verify what code ran and where, which is where attestation and key release policies matter. If you have compliance requirements around data residency and operator access, this is a reminder to evaluate not just encryption at rest/in transit, but encryption in use and the audit story around it.

Rowhammer protection built into Azure Cobalt 200

Microsoft shared how Azure Cobalt 200 implements a configurable, hybrid Rowhammer defense in the SoC memory controller, reinforcing last week's point that platform security is increasingly about built-in, default protections (not optional add-ons) that hold up even when higher-level telemetry is limited. The design aims for near-zero overhead under normal operation, while scaling protections when attack patterns appear, and it discusses constraints around telemetry in confidential computing environments where visibility can be intentionally limited.

If you run sensitive multi-tenant workloads, Rowhammer is a reminder that not all security boundaries are “software bugs”; some are physics-driven reliability attacks that need hardware mitigation. The post links to an ISCA 2026 paper with full design and evaluation details, which is useful for teams that need to understand threat models and performance trade-offs.

Data security for AI analytics: Purview, Fabric, gateways, and database governance

Fabric data protection: labels, DLP, and DSPM as Copilot/agents arrive

Microsoft detailed how Fabric integrates Microsoft Purview capabilities to reduce oversharing risk when Copilot and agents access enterprise analytics data, continuing last week's Fabric governance thread (identity-backed access to OneLake shortcuts and catalog role management) by focusing on the controls that make those connections safe at scale. The guidance highlights sensitivity labels, protection policies, Data Loss Prevention (DLP) controls (including restrict access in preview), and DSPM (Data Security Posture Management) for Fabric, along with governance features like the OneLake Catalog.

For developers and data teams, the useful framing is “AI-ready” data is not just about quality and lineage, it is about access boundaries that survive automation. If you are enabling agents over analytics, build label-driven access patterns early so you can scale from a handful of workspaces to broader adoption without turning every request into an exception process.

The June 2026 on-premises data gateway release (v3000.322) added Windows Web Account Manager (WAM) authentication support, updated the bundled Apache Log4j library to 2.25.4, and introduced consent-driven diagnostic uploads integrated into the Dataflow Gen2 run experience, which lines up with last week's “secure-by-default monitoring” focus by making it easier to get the right logs without ad hoc access. The Log4j bump is a small but important maintenance signal, since gateway components often sit in sensitive network positions and can be forgotten.

WAM support can simplify sign-in flows and help align gateway authentication with modern identity controls, depending on your environment. The diagnostics change also matters operationally: getting the right logs quickly (with explicit consent) is often the difference between a short-lived incident and a multi-day outage.

SQL and PostgreSQL tooling brings identity and security closer to the editor

On the PostgreSQL side, the VS Code PostgreSQL extension gained Azure Database for PostgreSQL performance monitoring and tuning features inside the editor, including a server metrics dashboard, Azure Advisor recommendations, query plan visualization, and AI-assisted query analysis, and it fits the same pattern we highlighted last week with Copilot CLI and agent workflows: security and governance controls need to follow developers into their primary tools. The post also references Microsoft Entra ID, which is increasingly the default path for consistent authentication and governance across data services.

In parallel, a “Microsoft SQL in 2026 so far” roundup collected security and identity improvements across Azure SQL, SQL Server 2025, and SQL database in Fabric, alongside developer tooling updates (SSMS, VS Code MSSQL extension) and new AI features like AI_GENERATE_EMBEDDINGS. For security-minded teams, the combined story is that database productivity features are arriving in the same places developers work, so guardrails (identity, auditing, least privilege) need to be equally “close to the keyboard.”

Oracle AI Database@Azure playbook: patterns with Entra ID and Purview

Microsoft published an Oracle AI Database@Azure AI adoption playbook that documents blueprint patterns like zero data movement, governed replication into Microsoft Fabric (including Oracle GoldenGate CDC), and an intelligence layer using Microsoft IQ, extending last week's theme that governance is catching up to where data actually lives (and moves) across Microsoft 365, Fabric, and cloud services. It also highlights security and governance guidance using Microsoft Entra ID and Microsoft Purview, which is a key combo when you are bridging platforms and need consistent identity and classification.

For teams integrating Oracle and Microsoft stacks, the practical value is having reference patterns that explicitly include governance, not just connectivity. If you are planning cross-system agent access (Copilot Studio, Azure AI Foundry), treat the playbook as a starting point for deciding where enforcement lives (source DB, replication pipeline, Fabric, or the agent layer).

Other Security News

Several items this week focused on security programs and the practical reality of AI-assisted development: teams need better guardrails, better APIs for automation, and clearer adoption paths, continuing last week's throughline that agent governance is becoming an operating model (not just guidance) across the SDLC and platform controls. A survey write-up noted that many developers believe AI-generated code has more vulnerabilities but still ship under delivery pressure, while Microsoft shared how it is applying an internal agentic platform across the SDLC to reduce toil in planning, review, security/compliance, and operations.

On the industry tooling side, Vercel launched eve (an open source agent framework) alongside enterprise controls like Passport and BYOC (bring your own cloud) positioned as a response to “shadow AI” using centralized identity via OpenID Connect. Microsoft also published a CNAPP (Cloud-Native Application Protection Platform) perspective describing a shift toward unified cloud risk operations with exploitability-based prioritization and code-to-cloud-to-SOC correlation, mapping those ideas to Microsoft Defender for Cloud. Finally, Microsoft Learn got a new Security Adoption Model resource to help teams plan and track security work across a journey/disciplines structure.