Security & IT News

Microsoft has pulled a buggy Windows 11 non-security preview update to investigate a known issue that triggers 0x80073712 errors during installation. [...]

This is the third update to the TeamPCP supply chain campaign threat intelligence report, When the Security Scanner Became the Weapon (v3.0, March 25, 2026). Update 002 covered developments through March 27, including the Telnyx PyPI compromise and Vect ransomware partnership. This update covers developments from March 27-28, 2026. HIGH: First 48-Hour Window Without a New Supply Chain Compromise The most operationally significant development in the last 24 hours is what did not happen: no new package compromises have been confirmed since the Telnyx disclosure on March 27. This is the first 48-hour window without a new ecosystem compromise since TeamPCP began active operations on March 19. The prior operational cadence was aggressive -- a new target every 1-3 days (Trivy March 19, CanisterWorm March 20-22, Checkmarx March 23, LiteLLM March 24, Telnyx March 27). The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests. Analysts assess this pause should not be interpreted as the end of supply chain operations. TeamPCP explicitly stated they intend to be around for a long time, and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries -- PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker's cost of operations on that platform. Recommended action: Maintain heightened monitoring posture. Use this operational window to complete credential rotations and IOC sweeps if not already done. The CISA KEV remediation deadline for CVE-2026-33634 is now 11 days away (April 8, 2026). HIGH: Palo Alto Networks Publishes Behavioral Detection Rules for CI/CD Pipeline Attacks Palo Alto Networks has published detection rules specifically designed to identify TeamPCP-style CI/CD pipeline attacks at the behavioral level rather than relying solely on IOC matching. This is significant because TeamPCP has demonstrated the ability to rotate infrastructure across each new compromise wave -- each phase used different C2 domains, different exfiltration endpoints, and different packaging techniques (raw scripts, npm worm, .pth exploitation, WAV steganography). Behavioral detection approaches focus on anomalous CI/CD runner behavior: unexpected credential directory enumeration, bulk secret reads from /proc/ pid /mem , large encrypted archive creation, and outbound data transfers to newly registered domains during workflow execution. These patterns have been consistent across all five TeamPCP compromise phases even as specific IOCs changed. Recommended action: Organizations with Palo Alto Networks security products should review and deploy the published detection rules. All organizations should evaluate whether their CI/CD monitoring can detect the

High-value assets including domain controllers, web servers, and identity infrastructure are frequent targets in sophisticated attacks. Microsoft Defender applies asset-aware protection using Microsoft Security Exposure Management to detect and block threats against these critical systems. This article explores real-world attack scenarios and defense techniques. As cyberthreats continue to grow in scale, speed, and sophistication, organizations must pay close attention to the systems that form their backbone: High-Value Assets (HVAs). These assets include the servers, services, identities, and infrastructure essential for business operations and security. Examples include domain controllers that manage authentication and authorization across the network; web servers hosting business-critical applications such as Exchange or SharePoint; identity systems that enable secure access across on-premises and cloud environments; and other components such as certificate authorities and internet-facing services that provide access to corporate applications. This reinforces a simple but important idea: not all assets carry the same risk, and protections should reflect their role and impact. To support this, we continue to expand differentiated protections for the assets that matter most. These efforts focus on helping organizations reduce risk, disrupt high-impact attack paths, and strengthen overall resilience. Microsoft Defender already provides enhanced protection for critical assets through capabilities such as automatic attack disruption . In this article, we explore how additional security layers further strengthen risk-based protection. Using asset context to strengthen detection In recent years, human-operated cyberattacks have evolved from sporadic, opportunistic intrusions into targeted campaigns designed to maximize impact. Analysis shows that in more than 78% of these attacks, threat actors successfully compromise a High-Value Asset, such as a domain controller, to gain deeper, elevated access within the organization. Traditional endpoint detection methods rely on behavioral signals such as process execution, command-line activity, and file operations. While effective in many scenarios, these signals often lack context about the asset being targeted. Administrative tools, scripting frameworks, and system utilities can appear identical in both legitimate and malicious use. This is where understanding a device’s role becomes essential. On high-value assets such as domain controllers or identity infrastructure, even small risks matter because the potential impact is significantly higher. Activities that may be routine on general-purpose servers or administrative workstations can indicate compromise when observed on Tier-0 systems. Defender incorporates a critical asset framework to enrich detection with this context. This intelligence is powered by Microsoft Security Exposure Management, where critical assets, attack paths, and cross-workload relati

​Microsoft has released the KB5079391 preview cumulative update for Windows 11 24H2 and 25H2, which includes 29 changes, such as Smart App Control and Display improvements. [...]

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. Checkmarx ast-github-action: All 91 Tags Were Compromised, Not Just v2.3.28 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: f1d2a3477e0d f58de2470825 aa52a82cddf2 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 Vuln

Apple released the next version of its operating system, patching 85 different vulnerabilities across all of them. None of the vulnerabilities are currently being exploited. The last three macOS generations are covered, as are the last two versions of iOS/iPadOS. For tvOS, watchOS, and visionOS, only the current version received patches. This update also includes the recently released Background Security Improvements. Some older watchOS versions received updates, but these updates do not address any security issues. iOS 26.4 and iPadOS 26.4 iOS 18.7.7 and iPadOS 18.7.7 macOS Tahoe 26.4 macOS Sequoia 15.7.5 macOS Sonoma 14.8.5 tvOS 26.4 watchOS 26.4 visionOS 26.4 Safari 26.4 Xcode 26.4 CVE-2025-43376: A remote attacker may be able to view leaked DNS queries with Private Relay turned on. Affects WebKit x CVE-2025-43534: A user with physical access to an iOS device may be able to bypass Activation Lock. Affects iTunes Store x CVE-2026-20607: An app may be able to access protected user data. Affects libxpc x x x CVE-2026-20631: A user may be able to elevate privileges. Affects PackageKit x CVE-2026-20632: An app may be able to access sensitive user data. Affects Music x CVE-2026-20633: An app may be able to access user-sensitive data. Affects Archive Utility x x x CVE-2026-20637: An app may be able to cause unexpected system termination. Affects AppleKeyStore x x x CVE-2026-20639: Processing a maliciously crafted string may lead to heap corruption. Affects configd x x CVE-2026-20643: Processing maliciously crafted web content may bypass Same Origin Policy. Affects WebKit x x x x x CVE-2026-20651: An app may be able to access sensitive user data. Affects Messages x CVE-2026-20657: Parsing a maliciously crafted file may lead to an unexpected app termination. Affects Vision x x x CVE-2026-20660: A remote user may be able to write arbitrary files. Affects CFNetwork x CVE-2026-20665: Processing maliciously crafted web content may prevent Content Security Policy from being enforced. Affects WebKit x x x x x x x CVE-2026-20668: An app may be able to access sensitive user data. Affects Focus x x x CVE-2026-20684: An app may bypass Gatekeeper checks. Affects AppleScript x CVE-2026-20687: An app may be able to cause unexpected system termination or write kernel memory. Affects Kernel x x x x x x CVE-2026-20688: An app may be able to break out of its sandbox. Affects Printing x x x x x CVE-2026-20690: Processing an audio stream in a maliciously crafted media file may terminate the process. Affects CoreMedia x x x x x x x x CVE-2026-20691: A maliciously crafted webpage may be able to fingerprint the user. Affects WebKit Sandboxing x x x x x CVE-2026-20692: Hide IP Address and Block All Remote Content may not apply to all mail content. Affects Mail x x x x CVE-2026-20693: An attacker with root privileges may be able to delete protected system files. Affects PackageKit x x x CVE-2026-20694: An app may be able to access user-sensitive data. Affects MigrationKit x x

Identity attacks no longer hinge on who a cyberattacker compromises, but on what that identity can access. As organizations manage growing numbers of human, non-human, and agentic identities, their access fabric multiplies across apps, resources, and environments, which increases both operational complexity for identity teams and risk exposure for security teams. Redefining identity security for the modern enterprise Read the blog ↗ The challenge isn’t just scale, it’s fragmentation. From our latest Secure Access report , research shows that 32% of organizations say their access management solutions are duplicative, and 40% say they have too many different vendors. That fragmentation for security vendors makes it harder to maintain consistent access controls and correlate risk across identities. When risk is distributed across dozens of disconnected accounts and permissions, visibility fragments and blind spots emerge—creating ideal conditions for cyberattackers to move laterally without detection. Securing identity in this reality requires more than incremental improvements. It calls for a shift from fragmented controls to an integrated, end-to-end approach that treats identity as a shared control plane that is informed by a continuous, foundational security signal. Why fragmentation fails—and what must replace it With the traditional model of identity security—built on siloed directories, disconnected access policies, and bolt-on threat detection—cyberattackers don’t have to break defenses, they just move between them. Permissions go uncorrelated, access policies drift as environments evolve, and lateral movement hides in the gaps. What is a Security Operations Center? Learn more ↗ For defenders, this creates a dangerous imbalance. Identity signals flood the security operations center (SOC) without the context to act, while identity teams enforce access without visibility into active cyberthreats. Risk accumulates across systems, but responsibility—and insight—remains fragmented. Fixing this doesn’t require more alerts or point solutions. It requires an integrated fabric that brings together all of the identities, access, and signals. A modern identity security solution must unify three critical layers: The identity infrastructure : The systems and services that underpin every access decision. This includes the identity provider, authentication services, single sign-on (SSO), user and group management, and the systems that establish and maintain trust across the enterprise. Without this foundation, there is no authoritative source of truth for who an identity is, what it can access, or how it should be governed. It’s the layer many security vendors lack—and the one Microsoft delivers at global scale. The identity control plane : Where privileged identity management and access decisions are enforced in real time, based on dynamic risk signals, behavioral context, and policy intent. This is where identity and security converge to adapt access as

Citrix has patched two NetScaler ADC and NetScaler Gateway vulnerabilities, one of which is very similar to the CitrixBleed and CitrixBleed2 flaws exploited in zero-day attacks in recent years. [...]

AI translation fixes multilingual content chaos by improving consistency, workflows, and speed, helping teams reduce errors and scale global content faster.

TP-Link has patched several vulnerabilities in its Archer NX router series, including a critical-severity flaw that may allow attackers to bypass authentication and upload new firmware. [...]

On March 19, 2026, Trivy, Aqua Security’s widely used open-source vulnerability scanner, was reported to have been compromised in a sophisticated CI/CD-focused supply chain attack. Threat actors leveraged access from a prior incident that was not fully remediated to inject credential-stealing malware into official releases of Aqua Security’s widely adopted open-source vulnerability scanner, Trivy. The attack simultaneously compromised the core scanner binary, the trivy-action GitHub Action, and the setup-trivy GitHub Action, weaponizing trusted security tooling against the organizations relying on it. The campaign, attributed to the threat actor identifying as TeamPCP, introduces several concerning techniques. This blog walks through the Trivy supply chain attack and explains how Microsoft Defender helps organizations detect, investigate, and respond to this incident. This activity has since expanded to additional frameworks, including Checkmarx KICS and LiteLLM, with further details to be shared as the investigation continues. Analyzing the Trivy supply chain compromise The activity on March 19 represents the execution phase of the campaign, where previously established access was used to weaponize trusted Trivy distribution channels: Poisoning GitHub Actions used in CI/CD pipelines: Using compromised credentials with tag write access, the attacker force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy, redirecting existing, trusted version references to malicious commits. This caused downstream workflows to execute attacker-controlled code without any visible change to release metadata. Publishing a malicious Trivy binary: In parallel, the attacker triggered release automation to publish an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries, exposing both CI/CD environments and developer machines to credential theft and persistence. Maintaining stealth and impact window: Both the compromised GitHub Actions and the malicious binary were designed to execute credential-harvesting logic in addition to the legitimate Trivy functionality, allowing workflows and scans to appear successful while secrets were exfiltrated. Attack containment by maintainers: Later that day, the Trivy team identified the compromise and removed malicious artifacts from distribution channels, ending the active propagation phase. How Git’s design was abused in the attack This attack exploited two aspects of how Git and GitHub operate by design: mutable tags and self-declared commit identity, turning expected platform behavior into an advantage for the attacker. In Git, a tag is a label that maps to a specific commit in the repository’s history. By default, these references are not immutable – anyone with push access can reassign an existing tag to point to an entirely different commit. The attacker did exactly that, replacing the targe

AI agents increasingly perform tasks that involve reasoning, acting, and interacting with other systems. Building a trusted agent requires ensuring it operates within the correct boundaries and performs tasks consistent with its intended purpose. In practice, this requires aligning several layers of intent: User intent : The goal or task the user is trying to accomplish. Developer intent : The purpose for which the agent was designed and built. Role-based intent: The specific function the agent performs within an organization. Organizational intent : Enterprise policies, standards, and operational constraints. For example, one department may adopt an agent developed by another team, customize it for a specific business role, require that it adhere to internal policies, and expect it to provide reliable results to end users. Aligning these intent layers helps ensure agents meet user needs while operating within organizational, security, and compliance boundaries. Importance of intent alignment A successful and trusted AI agent must satisfy what the user intended to accomplish, while operating within the bounds of what the developer, role, and organization intended it to do. Proper intent alignment empowers AI agents to: Deliver quality results that accurately address user requests and solve real problems, increasing trust and productivity. Ensure the agent maintains its intended goal and operates within the boundaries it was developed and deployed for, reflecting the developer’s original design and the job to be done by the deploying organization. Uphold security and compliance by respecting organizational policies, protecting data, and preventing misuse or unauthorized actions. User Intent: The Key to Quality Outcomes Every AI agent interaction begins with the user’s objective, the task the user is trying to complete. Correctly interpreting that objective is essential to producing useful results. If the agent misinterprets the request, the response may be irrelevant, incomplete, or incorrect. Modern agents often go beyond simple question answering. They interpret requests, select tools or services, and perform actions to complete a task. Evaluating alignment with user intent therefore requires examining whether the agent correctly interprets the request, chooses the appropriate tools, and produces a coherent response. For example, when a user submits the query “Weather now,” an agent must infer that the user wants the current local weather. It must retrieve the relevant location and weather data through available APIs and present the result in a clear response. Developer intent: Defining the agent’s intended scope If user intent is about what the user wants the agent to do, developer intent is about what was the agent developed for. Developer’s intent defines the quality that of how well the agent fulfills its intended job, and the security boundaries that protect the agent from misuse or drift. In short, developer intent defines how the agent ar

A critical vulnerability in Citrix’s NetScaler products allows unauthenticated remote attackers to leak information from the appliance's memory

So, I've been slow to get on the Claude Code/OpenCode/Codex/OpenClaw bandwagon, but I had some time last week so I asked Claude to review ( /security-review ) some of my python scripts. He found more than I'd like to admit, so I checked in a bunch of updates. In reviewing his suggestions, he was right, I made some stupid mistakes, some of which have been sitting in there for a long time. It was nothing earth-shattering and it took almost no time for Claude, it took longer for me to read through the updates he wanted to make, figure out what he was seeing, and decide whether to accept them or tweak them. Here are a few of them. a logic inversion error with the -f switch, and some unhandled errors in convert-ts-bash-history.py a TOCTOU (time of check/time of use) possible race condition, and a comment about some ambiguity with the -c switch when deciding which hash was used based solely on the length of the hash in sigs.py some overly permissive permissions, a possible symlink attack, and an encoding issue in ficheck.py a possible header injection issue via the -s switch with mail_stuff.py Most of these are issues I should have caught myself given how long I've been programming/scripting, but all of these started out as quick and dirty scripts to solve a problem I had, and then I made them available to the public through my github repo without taking any time to really ensure they were ready for public consumption. Taking a few minutes to setup Claude without much in the way of guidance (my CLAUDE.md is still very much a work-in-progress) and the one in my my scripts repo was one I asked Claude to create for me after some back and forth during this review which mostly covers a couple of personal preferences. I guess the main point is I'm late to the game on using AI on a daily basis, but that needs to change. Even when I'm feeling my age and write my own scripts, I need to have that second pair of eyes give it a second look. Some of these scripts run as root out of cron or systemd timers on systems I administer and some of those issues could have been used for privilege escalation by an attacker who managed to get access. Even those of us with more grey than not in our beards need to be spending some time figuring out how to integrate this stuff into our daily routine. References : [1] https://github.com/clausing/scripts --------------- Jim Clausing, GIAC GSE #26 jclausing --at-- isc [dot] sans (dot) edu (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Excerpt: CTI-REALM is Microsoft’s open-source benchmark for evaluating AI agents on real-world detection engineering—turning cyber threat intelligence (CTI) into validated detections. Instead of measuring “CTI trivia,” CTI-REALM tests end-to-end workflows: reading threat reports, exploring telemetry, iterating on KQL queries, and producing Sigma rules and KQL-based detection logic that can be scored against ground truth across Linux, AKS, and Azure cloud environments. Security is Microsoft’s top priority. Every day, we process more than 100 trillion security signals across endpoints, cloud infrastructure, identity, and global threat intelligence. That’s the scale modern cyber defense demands, and AI is a core part of how we protect Microsoft and our customers worldwide. At the same time, security is, and always will be, a team sport. That’s why Microsoft is committed to AI model diversity and to helping defenders apply the latest AI responsibly. We created CTI‑REALM and open‑sourced it so the broader industry can test models, write better code, and build more secure systems together. CTI-REALM (Cyber Threat Real World Evaluation and LLM Benchmarking) is Microsoft’s open-source benchmark that evaluates AI agents on end-to-end detection engineering. Building on work like ExCyTIn-Bench , which evaluates agents on threat investigation, CTI-REALM extends the scope to the next stage of the security workflow: detection rule generation. Rather than testing whether a model can answer CTI trivia or classify techniques in isolation, CTI-REALM places agents in a realistic, tool-rich environment and asks them to do what security analysts do every day: read a threat intelligence report, explore telemetry, write and refine KQL queries, and produce validated detection rules. We curated 37 CTI reports from public sources (Microsoft Security, Datadog Security Labs, Palo Alto Networks, and Splunk), selecting those that could be faithfully simulated in a sandboxed environment and that produced telemetry suitable for detection rule development. The benchmark spans three platforms: Linux endpoints, Azure Kubernetes Service (AKS), and Azure cloud infrastructure with ground-truth scoring at every stage of the analytical workflow. Why CTI-REALM exists Existing cybersecurity benchmarks primarily test parametric knowledge: can a model name the MITRE technique behind a log entry, or classify a TTP from a report? These are useful signals. However, they miss the harder question: can an agent operationalize that knowledge into detection logic that finds attacks in production telemetry? No current benchmark evaluates this complete workflow. CTI-REALM fills that gap by measuring: Operationalization, not recall: Agents must translate narrative threat intelligence into working Sigma rules and KQL queries, validated against real attack telemetry. The full workflow: Scoring captures intermediate decision quality—CTI report selection, MITRE technique mapping, data source identi

Next week, RSAC™ Conference celebrates its 35-year anniversary as a forum that brings the security community together to address new challenges and embrace opportunities in our quest to make the world a safer place for all. As we look towards that milestone, agentic AI is reshaping industries rapidly as customers transform to become Frontier Firms —those anchored in intelligence and trust and using agents to elevate human ambition, holistically reimagining their business to achieve their highest aspirations. Our recent research shows that 80% of Fortune 500 companies are already using agents. 1 At the same time, this innovation is happening against a sea change in AI-powered attacks where agents can become “ double agents .” And chief information officers (CIOs), chief information security officers (CISOs), and security decision makers are grappling with the resulting security implications: How do they observe, govern, and secure agents? How do they secure their foundations in this new era? How can they use agentic AI to protect their organization and detect and respond to traditional and emerging threats? The answer starts with trust, and security has always been the root of trust. In this agentic era, security must be woven into, and around, every layer of the AI estate. It must be ambient and autonomous, just like the AI it protects. This is our vision for security as the core primitive of the AI stack. At RSAC 2026, we are delivering on that vision with new purpose-built capabilities designed to help organizations secure agents, secure their foundations, and defend using agents and experts. Fueled by more than 100 trillion daily signals, Microsoft Security helps protect 1.6 million customers, one billion identities, and 24 billion Copilot interactions. 2 Read on to learn how we can help you secure agentic AI. Secure agentic AI with Microsoft Security Secure agents Earlier this month, we announced that Agent 365 will be generally available on May 1. Agent 365—the control plane for agents —gives IT, security, and business teams the visibility and tools they need to observe, secure, and govern agents at scale using the infrastructure you already have and trust. It includes new Microsoft Defender, Entra, and Purview capabilities to help you secure agent access, prevent data oversharing, and defend against emerging threats. Agent 365 is included in Microsoft 365 E7: The Frontier Suite along with Microsoft 365 Copilot, Microsoft Entra Suite, and Microsoft 365 E5, which includes many of the advanced Microsoft Security capabilities below to deliver comprehensive protection for your organization. Learn more about Microsoft Agent 365 Secure your foundations Along with securing agents, we also need to think of securing AI comprehensively. To truly secure agentic AI, we must secure foundations—the systems that agentic AI is built and runs on and the people who are developing and using AI. At RSAC 2026, we are introducing new capabilities to help you gain

Overview Rapid7 Labs recently identified a chain of security vulnerabilities in the Gainsight Assist plugin and its interactions with the associated domain app.gainsight.com . These vulnerabilities include an Information Disclosure flaw ( CVE-2026-31381 ) and a Reflected Cross-Site Scripting (XSS) vulnerability ( CVE-2026-31382 ). By chaining these vulnerabilities, an attacker can move from passive information gathering to active client-side exploitation. The XSS vulnerability was remediated by Gainsight via a server side code-level fix on March 6, 2026. A patched update to the Chrome and Outlook plugins to remediate the Information Disclosure were released on March 9, 2026. Product description Gainsight Assist is a plugin that allows users to access Gainsight email templates and easily sync inbound and outbound emails to the Timeline within the Gainsight Customer Success (CS) product directly from their email platform. Credit These vulnerabilities were discovered and reported to the Gainsight team by Christopher O’Boyle, Cybersecurity Advisor at Rapid7. The vulnerabilities are being disclosed in accordance with Rapid7's vulnerability disclosure policy . Rapid7 is grateful to the Gainsight team for their assistance and collaboration. Vulnerability details CVE Description CVSS CVE-2026-31381 Information Disclosure: An attacker can extract user email addresses (PII) exposed in base64 encoding via the state parameter in the OAuth callback URL. 5.3 (Medium) CVE-2026-31382 Reflected XSS / HTML Injection: The error_description parameter is vulnerable to Reflected XSS. An attacker can bypass the domain's WAF using a Safari-specific onpagereveal payload. 6.1 (Medium) The testing target was the Gainsight Assist plugin and its interactions with the app.gainsight.com domain, used as a callback mechanism that processes authentication data and error descriptions following user login attempts. CVE-2026-31381: Information disclosure During testing involving Salesforce and Okta authentication channels, an OAuth callback flow failure was observed. The resulting error message exposed the user's email address (PII) within a Base64 encoded state parameter in the URL. Because Base64 is merely obfuscation and not encryption, these email addresses can be easily harvested from server logs, proxies, or browser history by third parties. CVE-2026-31382: Reflected XSS and HTML injection The Gainsight callback URL contained an error_description parameter that was found to be vulnerable to content spoofing and HTML Injection. While Gainsight employs a Web Application Firewall (WAF) that successfully blocks most standard JavaScript execution, Rapid7 researchers bypassed this protection using a browser-specific payload targeting Safari’s onpagereveal event. When the victim opens the malicious URL in Safari, the onpagereveal payload executes automatically without further user interaction. By injecting HTML content and spoofing the error page, an attacker can create a legitimate-

Over the past year, I have had conversations with security leaders across a variety of disciplines, and the energy around AI is undeniable. Organizations are moving fast, and security teams are rising to meet the moment. Time and again, the question comes back to the same thing: “We’re adopting AI fast, how do we make sure our security keeps pace?” Explore the updated Microsoft Zero Trust Workshop and Assessment It’s the right question, and it’s the one we’ve been working to answer by updating the tools and guidance you already rely on. We’re announcing Microsoft’s approach to Zero Trust for AI (ZT4AI). Zero Trust for AI extends proven Zero Trust principles to the full AI lifecycle—from data ingestion and model training to deployment and agent behavior. Today, we’re releasing a new set of tools and guidance to help you move forward with confidence: A new AI pillar in the Zero Trust Workshop . Updated Data and Networking pillars in the Zero Trust Assessment tool. A new Zero Trust reference architecture for AI. Practical patterns and practices for securing AI at scale. Here’s what’s new and how to use it. Why Zero Trust principles must extend to AI AI systems don’t fit neatly into traditional security models. They introduce new trust boundaries—between users and agents, models and data, and humans and automated decision-making. As organizations adopt autonomous and semi-autonomous AI agents, a new class of risk emerges: agents that are overprivileged, manipulated, or misaligned can act like “double agents,” working against the very outcomes they were built to support. Watch the video: AI with Zero Trust Security By applying three foundational principles of Zero Trust to AI: Verify explicitly —Continuously evaluate the identity and behavior of AI agents, workloads, and users. Apply least privilege —Restrict access to models, prompts, plugins, and data sources to only what’s needed. Assume breach —Design AI systems to be resilient to prompt injection, data poisoning, and lateral movement. These aren’t new principles. What’s new is how we apply them systematically to AI environments. A unified journey: Strategy → assessment → implementation The most common challenge we hear from security leaders and practitioners is a lack of a clear, structured path from knowing what to do to doing it. That’s what Microsoft’s approach to Zero Trust for AI is designed to solve—to help you get to next steps and actions, quickly. Zero Trust Workshop—now with an AI pillar Building on last year’s announcement , the Zero Trust Workshop has been updated with a dedicated AI pillar, now covering 700 security controls across 116 logical groups and 33 functional swim lanes. It is scenario-based and prescriptive, designed to move teams from assessment to execution with clarity and speed. The workshop helps organizations: Align security, IT, and business stakeholders on sha

Adoption of Generative AI (GenAI) and agentic AI has accelerated from experimentation into real enterprise deployments. What began with copilots and chat interfaces has quickly evolved into powerful business systems that autonomously interact with sensitive data, call external APIs, connect to consequential tools, initiate workflows, and collaborate with other agents across enterprise environments. As these AI systems become core infrastructure, establishing clear, continuous visibility into how these systems behave in production can help teams detect risk, validate policy adherence, and maintain operational control. Observability is one of the foundational security and governance requirements for AI systems operating in production. Yet many organizations don’t understand the critical importance of observability for AI systems or how to implement effective AI observability. That mismatch creates potential blind spots at precisely the moment when visibility matters most. In February, Microsoft Corporate Vice President and Deputy Chief Information Security Officer, Yonatan Zunger, blogged about expanding Microsoft’s Secure Development Lifecycle (SDL) to address AI-specific security concerns. Today, we continue the discussion with a deep dive into observability as a necessity for the secure development of GenAI and agentic AI systems. For additional context, read the Secure Agentic AI for Your Frontier Transformation blog that covers how to manage agent sprawl, strengthen identity controls, and improve governance across your tenant. Observability for AI systems In traditional software, client apps make structured API calls and backend services execute predefined logic. Because code paths follow deterministic flows, traditional observability tools can surface straightforward metrics like latency, errors, and throughput to track software performance in production. GenAI and agentic AI systems complicate this model. AI systems are probabilistic by design and make complex decisions about what to do next as they run. This makes relying on predictable finite sets of success and failure modes much more difficult. We need to evolve the types of signals and telemetry collected so that we can accurately understand and govern what is happening in an AI system. Consider this scenario: an email agent asks a research agent to look up something on the web. The research agent fetches a page containing hidden instructions and passes the poisoned content back to the email agent as trusted input. The email agent, now operating under attacker influence, forwards sensitive documents to unauthorized recipients, resulting in data exfiltration. In this example, traditional health metrics stay green: no failures, no errors, no alerts. The system is working exactly as designed… except a boundary between untrusted external content and trusted agent context has been compromised. This illustrates how AI systems require a unique approach to observability. Without insights

As organizations adopt AI, security and governance remain core primitives for safe AI transformation and acceleration. After all, data leaders are aware of the notion that: Your AI is only as good as your data. Organizations are skeptical about AI transformation due to concerns of sensitive data oversharing and poor data quality. In fact, 86% of organizations lack visibility into AI data flows, operating in darkness about what information employees share with AI systems [1] . Compounding on this challenge, about 67% of executives are uncomfortable using data for AI due to quality concerns [2]. The challenges of data oversharing and poor data quality requires organizations to solve these issues seamlessly for the safe usage of AI. Microsoft Purview offers a modern, unified approach to help organizations secure and govern data across their entire data estate, in particular best in class integrations with M365, Microsoft Fabric, and Azure data estates, streamlining oversight and reducing complexity across the estate. At FabCon Atlanta, we’re announcing new Microsoft Purview innovations for Fabric to help seamlessly secure and confidently activate your data for AI transformation. These updates span data security and data governance, granting Fabric users to both Discover risks and prevent data oversharing in Fabric Improve governance processes and data quality across their data estate 1. Discover risks and prevent data oversharing in Fabric As data volume increases with AI usage, Microsoft Purview secures your data with capabilities such as Information Protection, Data Loss Prevention (DLP), Insider Risk Management (IRM), and Data Security Posture Management (DSPM). These capabilities work together to secure data throughout its lifecycle and now specifically for your Fabric data estate. Here are a few new Purview innovations for your Fabric estate: Microsoft Purview DLP policies to prevent data leakage for Fabric Warehouse and KQL/SQL DBs Now generally available, Microsoft Purview DLP policies allow Fabric admins to prevent data oversharing in Fabric through policy tip triggering when sensitive data is detected in assets uploaded to Warehouses. Additionally, in preview, Purview DLP enables Fabric admins to restrict access to assets with sensitive data in KQL/SQL DBs and Fabric Warehouses to prevent data oversharing. This helps admins limit access to sensitive data detected in these data sources and data stores to just asset owners and allowed collaborators. These DLP innovations expand upon the depth and breadth of existing DLP policies to ensure sensitive data in Fabric is protected. Figure 1. DLP restrict access preventing data oversharing of customer information stored in a KQL database. Microsoft Purview Insider Risk Management (IRM) indicators for Lakehouse, IRM data theft quick policy for Fabric, and IRM pay-as-you-go usage report for Fabric Microsoft Purview Insider Risk Management is now generally available for Microsoft Fabric extending its