Weekly Security Roundup: Post-Compromise, Tokens, and Agents

by TechHub

This week in Security, the spotlight is on what happens after initial access: Microsoft reported active exploitation of the Linux “Dirty Frag” local privilege escalation path, a reminder that containment and patching for LPE issues cannot wait. Threat research reinforced the same theme of attackers leaning on real workflows, from AiTM phishing that steals cloud authentication tokens to ClickFix-style macOS lures that push users into running Terminal commands. On the platform side, guidance and tooling matured around securing AI agents (least-privilege tokens, centralized governance, and safer PR review) while GitHub and Azure shipped practical improvements for earlier DevSecOps scanning, code-to-cloud risk correlation, and hardened container distribution paths.

This Week's Overview

Active exploitation: Linux “Dirty Frag” raises the stakes after initial compromise

Building on last week's focus on interrupting intrusion chains with automation (rather than only catching initial access), Microsoft reported active exploitation of a Linux local privilege escalation technique dubbed “Dirty Frag”, which expands what an attacker can do after they already have a foothold on a host. The write-up focuses on exploitation paths involving esp4/esp6 and rxrpc, with attention on how this can turn a low-privileged post-compromise position into root-level control.

For defenders, this is a reminder to treat local privilege escalation as an urgent containment risk, not a “later” patching item. Microsoft also published interim mitigations and mapped detections in Microsoft Defender, which helps security teams move quickly while kernel fixes and distro updates roll out through standard channels.

Threat research: token theft and social engineering continue to target real workflows

Following last week's incident writeups that showed how attackers get “hands-on keyboard” outcomes through token abuse and remote assistance, two investigations this week tracked attackers leaning on “make the user do it” techniques: one campaign stole cloud auth tokens using adversary-in-the-middle (AiTM) infrastructure, and another used fake macOS utilities that trick users into pasting Terminal commands. Both patterns bypass a lot of traditional “malware dropper” expectations, so detection and user friction (like strong sign-in protection and device signals) matter more than file-based scanning alone.

“Code of conduct” AiTM phishing leading to token compromise

Building on last week's token-centric framing (where stealing session artifacts is often the real goal), Microsoft detailed a multi-stage phishing campaign themed around “code of conduct” messaging that ultimately funneled targets through an AiTM flow to steal authentication tokens. Because AiTM sits between the user and the real sign-in, it can capture session artifacts even when users type credentials into what looks like a normal login sequence.

The post includes mitigations and concrete Defender coverage, including hunting guidance and indicators of compromise (IOCs). Teams running Microsoft Entra ID Protection and Microsoft Defender XDR should review sign-in risk policies and token protections with this tradecraft in mind, especially for high-value roles and admin portals.

ClickFix-style macOS lures that rely on pasted Terminal commands

In the same “user-mediated execution” vein as last week's Quick Assist social engineering chain (different platform, same playbook), Microsoft also documented updated ClickFix campaigns that push fake macOS utilities and guide users into running attacker-provided Terminal commands. The write-up breaks down multiple variants, how they establish persistence (including LaunchAgents and LaunchDaemons), and how operators evolve C2 discovery and payload delivery for infostealers.

For responders, the practical value is in the included Defender detections, KQL hunting queries, and the IOC set you can feed into your own detection pipelines. The trade-off is clear: controls that reduce “copy/paste to Terminal” behavior (plus device hardening and least privilege) can remove entire classes of successful execution paths.

Security for AI agents and agent-driven workflows: least privilege, governance, and safer reviews

Continuing last week's shift from “agentic” enthusiasm to enforceable guardrails (policy at tool boundaries, audit trails, and bounded identity), security guidance for AI agents got more concrete this week, spanning authorization patterns, centralized governance, and pragmatic review techniques for agent-generated changes. The common thread is shifting from “trust the agent output” to enforceable controls: scoped tokens, auditable gateways, and consistent review guardrails for code and CI.

Least-privilege authorization patterns for agents (OAuth token exchange + short-lived JWTs)

Curity and Microsoft published an azd template that deploys an Azure AI agent application using a least-privilege design based on short-lived OAuth 2.0 JWTs and token exchange. The template combines Microsoft Entra ID and Curity Identity Server, adds API gateways with audit logging, and uses layered Bicep deployments targeting Azure Container Apps.

For teams building agents that call internal APIs, the main win is avoiding long-lived credentials and reducing blast radius when prompts, tools, or endpoints are abused. The token exchange approach is a practical fit for agent architectures where you want strict, per-call authorization tied to JWT claims, rather than broad service principals that gradually become “god tokens”.

Governing “agent sprawl” with a multi-region landing zone architecture

This builds directly on last week's MCP/AGT governance thread by applying the same “central control plane” idea at platform scale: a reference architecture proposed a multi-region AI agent landing zone on Azure that layers Azure API Management AI Gateway, Azure AI Foundry Control Plane, and Microsoft Agent 365. The design focuses on policy enforcement, safety controls, evaluation, and centralized oversight so agents do not proliferate as untracked services with inconsistent access and logging.

The practical takeaway is architectural: treat agents as a platform capability with shared controls (identity, gateway policy, evaluation, and audit) rather than one-off apps. If you are already standardizing landing zones for AKS or PaaS, this is the analogous blueprint for agent services, especially across regions where governance drift tends to happen.

How to review agent-generated pull requests without weakening CI or permissions

GitHub published a review checklist aimed at the growing volume of agent-authored pull requests, which complements last week's emphasis on turning agent capabilities into auditable, policy-bound workflows by showing where “agent output” can quietly weaken the controls around it. Examples include subtly weakened CI (or changes that bypass checks), duplicated utility code, logic bugs that still satisfy limited assertions, and workflow-level security risks like prompt injection.

A key point for maintainers is to review the plumbing as much as the feature: validate GitHub Actions changes, verify GITHUB_TOKEN permissions are minimally scoped, and watch for new or expanded third-party actions. If your team is adopting agentic workflows, this kind of checklist can be turned into a CODEOWNERS-driven review requirement for workflow files and security-sensitive paths.

DevSecOps scanning upgrades: MCP-based pre-PR checks, CodeQL language coverage, and better triage UX

Building on last week's supply chain and GitHub Advanced Security coverage (better dependency inventory and faster, more actionable security signals), several GitHub security updates landed this week that push scanning earlier (into agent and IDE tooling) and make vulnerability management less painful at scale. The theme is reducing the “security review tax” by catching secrets and dependency issues before code hits a PR, while improving CodeQL coverage and advisory triage workflows.

GitHub MCP Server: secret scanning GA and dependency scanning public preview

Following last week's focus on governing MCP tool execution, secret scanning in the GitHub MCP (Model Context Protocol) Server is now generally available, enabling MCP-compatible agents and IDEs to detect exposed secrets before commits or pull requests. The GA release honors existing push protection customization, which matters if your org relies on specific bypass rules and enforcement behavior.

Alongside that, dependency scanning via GitHub MCP Server entered public preview, using Dependabot tooling and the GitHub Advisory Database to flag vulnerable dependencies as changes are drafted. Together, these features signal a shift toward “security checks as tools” for agent workflows, where the agent can ask GitHub for authoritative results instead of guessing from local heuristics.

CodeQL 2.25.3 adds Swift 6.3 support (plus query improvements)

CodeQL 2.25.3 shipped with Swift 6.3 support, extending CodeQL-based code scanning to teams building or modernizing Apple platform code. The release also includes extractor and query improvements across languages, including higher-precision C/C++ queries and refinements to GitHub Actions security queries.

For security engineering teams, the practical implication is fewer “blind spots” across polyglot repos, and better signal quality where CodeQL historically produced noisy results. If you gate merges on CodeQL, plan time to validate any query-suite behavior changes, especially in C/C++ and workflow scanning where false positives can quickly erode trust.

Repository security advisories get search and filters

GitHub added a search and filter bar to repository security advisories, enabling faster lookup by fields like severity, package, and ecosystem. This is a small UI change that can save a lot of time when you are coordinating multi-package disclosures or trying to reconcile advisories with SBOM outputs and dependency inventories.

For maintainers, this improves the day-to-day workflow of triaging advisories and confirming what is affected without exporting data or relying on external spreadsheets. It is especially helpful in monorepos and orgs that publish multiple packages across ecosystems (npm, Maven, PyPI) where “find the right advisory” becomes a recurring task.

GitHub REST API deprecation: /rate_limit loses code_scanning_upload field (May 19, 2026)

GitHub announced it will remove the code_scanning_upload field from the /rate_limit REST API response on May 19, 2026. Any scripts that parse this field for monitoring or backoff behavior should be updated now to avoid brittle failures.

This is a good prompt to audit internal tooling that wraps the GitHub API, especially security automation that uploads SARIF or interacts with code scanning at scale. If you centralize rate limit telemetry, confirm you are not keying dashboards or alerts on the deprecated property.

Cloud data and platform security: OneLake GA security and code-to-cloud risk correlation

Continuing last week's “data movement and egress controls” thread in Fabric (tightening where data can go, and making governance enforceable), security improvements this week also targeted the “data plane meets engineering workflow” boundary, where access models and runtime context often lag behind developer velocity. Two updates stood out: Microsoft Fabric tightened OneLake governance with GA security features, and GitHub added runtime risk context through Defender for Cloud integration.

OneLake security is generally available in Microsoft Fabric

OneLake security reached general availability in Microsoft Fabric, rolling out with default enablement and a more guided role management experience. The update includes inline validation for row-level security (RLS), a role creation wizard that covers both RLS and column-level security (CLS), and new REST APIs for role management.

For teams treating Fabric as a shared data platform, the key improvement is operational: security becomes easier to configure consistently, and more automatable via APIs. This matters when you have mirrored data, Private Link connectivity, and multiple personas (engineers, analysts, BI authors) that need different slices of the same datasets.

Code-to-cloud risk visibility with Microsoft Defender for Cloud is GA in GitHub

This extends last week's theme of joining up supply chain signals (dependency graphs, SBOMs, pipeline guidance) with operational reality: GitHub announced general availability of Microsoft Defender for Cloud integration with GitHub Advanced Security, providing code-to-cloud correlation for deployed container artifacts. In practice, this surfaces runtime risk context inside GitHub security views and adds runtime-aware filters and campaign targeting across code scanning and Dependabot.

For AppSec teams, the workflow impact is big even if the feature is “just correlation”: it helps answer whether a vulnerable component is actually running in production and where, without jumping between tools and dashboards. If you already use artifact attestations and the Deployment Record API, this is a path toward tighter feedback loops between deployment and remediation.

Identity and passwordless: passkeys momentum with Entra ID recovery changes

Building on last week's identity-first framing (shrinking ambient privilege and reducing token/session abuse), Microsoft used World Passkey Day to summarize recent progress on passwordless sign-in across Microsoft Entra ID, Windows, and consumer experiences. A notable operational detail is that Entra ID account recovery improvements are now generally available, and Microsoft plans to remove security questions as a reset option starting January 2027.

For organizations pushing phishing-resistant authentication, this reinforces that the “last mile” is often recovery and fallback paths. If you are rolling out FIDO2/passkeys, review account recovery policies and helpdesk procedures now so you do not end up with a strong primary factor but weak recovery controls that attackers can target.

Hardware-rooted security and memory safety: open designs, verifiable protection, and CHERI for embedded

Two announcements reinforced a growing shift toward verifiable security properties at the hardware layer, which complements last week's focus on controls you can actually operationalize (telemetry, enforcement, and audit) by strengthening the layers those controls depend on. Open-sourcing HSM components improves transparency, and CHERI-based capability hardware aims to reduce memory safety bugs. Both are long-term plays, but they influence what “secure by design” can realistically mean in cloud and embedded environments.

Azure Integrated HSM is being open-sourced (OCP) for trust and transparency

Microsoft announced it is open-sourcing Azure Integrated HSM via the Open Compute Project, including firmware and supporting software plus independent validation artifacts. The post positions server-integrated HSMs as complementary to Azure Key Vault and Managed HSM, aiming for hardware-enforced key protection that can be validated at scale.

For security architects, the key point is auditability: open designs and shared validation artifacts can make it easier to evaluate the hardware trust boundary rather than treating it as a black box. If you depend on HSM-backed key custody for regulated workloads, this kind of transparency can help with compliance narratives and third-party assurance.

CHERIoT-Ibex brings CHERI capability protections to an open RISC-V core

CHERIoT-Ibex is an open-source CHERIoT/CHERI-enabled RISC-V Ibex core, certified by the CHERI Alliance, designed to reduce memory safety vulnerabilities via hardware-enforced protections. It focuses on fine-grained compartmentalization aimed at embedded systems, where traditional memory safety mitigations can be expensive or incomplete.

The practical significance is architectural: CHERI capabilities (bounds and permissions enforced in hardware) can prevent classes of bugs like out-of-bounds access and certain use-after-free exploitation patterns. For teams building firmware or embedded platforms, this is a signal that memory safety can increasingly be addressed below the language level, not only via rewriting in Rust or adding runtime checks.

Supply chain and runtime hardening: audits and safer container distribution paths

This continues last week's supply chain focus (npm compromise guidance, stronger dependency graphs) by shifting from “what did we pull into the build” to “what privileged tooling and artifacts run in production.” Two items this week focused on reducing real-world operational risk: an independent audit for a Kubernetes inspection tool, and an Azure Container Registry feature that improves how images are promoted and cached across registries. Both are the kind of foundational changes that reduce incident likelihood without changing product features.

Inspektor Gadget completes its first independent security audit

Inspektor Gadget published results from its first independent security audit, including three patched vulnerabilities (notably CVE-2026-24905 and CVE-2026-25996) and additional hardening recommendations. Given Inspektor Gadget's role inspecting Kubernetes and Linux hosts (often with powerful privileges and eBPF access), audit findings are directly relevant to cluster security posture.

The report highlights practical areas teams should double-check in their own deployments, including RBAC and deployment hardening choices that affect blast radius. If you run Inspektor Gadget in production clusters, confirm you have picked up the patched versions and review the recommended hardening steps as part of cluster baseline configuration.

Azure Container Registry Artifact Cache can now use another ACR as an upstream source

Azure Container Registry (ACR) Artifact Cache added support for using another ACR as an upstream source, enabling ACR-to-ACR pull-through caching. This supports common promotion and registry hierarchy setups, where you want to control what reaches production registries while still benefiting from caching and reducing repeated pulls from external sources.

The walkthrough includes supported networking and auth combinations and demonstrates using Azure CLI with a user-assigned managed identity plus RBAC role assignments. For platform teams, this is a useful building block for supply chain hygiene: combine controlled upstreams, Private Link connectivity, and identity-based access to reduce credential sprawl and untracked image movement.

Other Security News

Several additional posts this week focused on making security more operational in real deployments, from mainframe integration modernization to practical key management and production deployment patterns for agents. A recurring theme is “secure-by-default plumbing”: identity integration, private networking, and automation that reduces manual exceptions.