Threats Tagged 'cloud'

Microsoft fixed critical vulnerabilities across Azure, Entra, and SharePoint, while Apple patched a high-severity authentication bypass. The post Microsoft, Apple Release Fresh Security Updates appeared first on SecurityWeek .

Bulletin ID: 2026-077-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 08/06/2026 11:00 AM PDT Description: Strands Agents is an open-source SDK for building AI agents. The strands-agents-tools package provides pre-built tools for use with the SDK, including the mongodb_memory, elasticsearch_memory, and mem0_memory tools for storing and retrieving agent memories. We identified CVE-2026-19111, an insecure direct object reference (IDOR) issue in the mongodb_memory, elasticsearch_memory, and mem0_memory tools. Each tool uses a namespace field as the sole tenant-isolation key, and that namespace was exposed as a parameter the large language model (LLM) could control through the tool schema. A crafted prompt could cause a tool to emit a call with a forged namespace, allowing a remote authenticated user to read, modify, or delete memories belonging to other tenants, or to inject false memories into another tenant's namespace. The standalone mongodb_memory and elasticsearch_memory functions additionally exposed connection parameters, which could allow the memory layer to be redirected to an actor-specified cluster. Impacted versions: < 0.8.3 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

A 26-year-old Canadian man once described as one of the most consequential cybercrime threat actors of 2024 has pleaded guilty to computer fraud and conspiracy to hack and extort more than 165 organizations that used the cloud provider Snowflake . Connor Riley Moucka , of Kitchener, Ontario, also admitted to stealing call and text history records of more than 100 million AT&T customers. A surveillance photo of Connor Riley Moucka, a.k.a. “Judische” and “Waifu,” dated Oct 21, 2024, 9 days before Moucka’s arrest. This image was included in an affidavit filed by an investigator with the Royal Canadian Mounted Police (RCMP). The U.S. Justice Department said between February and October 2024, Moucka and co-conspirators used stolen login credentials to steal cloud-hosted data belonging to at least 165 customers of a U.S.-based software-as-a-service company. The hackers targeted stolen credentials for Snowflake customer accounts that did not enforce multi-factor authentication, and extorted or attempted to extort a host of well-known companies, including TicketMaster, Lending Tree, Advance Auto Parts and Neiman Marcus. Snowflake responded to the data thefts by increasing password complexity requirements and enforcing multi-factor authentication. Moucka adopted new nicknames frequently — sometimes operating multiple identities concurrently — but two of his best-known monikers were “ Judische ” and “ Waifu .” Judische’s admitted role in the Snowflake data thefts was first documented by KrebsOnSecurity in a September 2024 story about the overlap between Western, English-speaking cybercriminals and extremist groups that harass and extort minors into harming themselves or others. That September 2024 story identified Judische as a software engineer from Ontario who has been involved in numerous data breaches and voice phishing attacks against U.S. companies since at least 2020. A little more than a month later, Canadian authorities arrested Moucka on a provisional warrant from the United States. The government says Moucka and others used their unauthorized access to steal billions of sensitive customer records and download terabytes of information, “including individuals’ non-content call and text history records, banking and other financial information, payroll records, Drug Enforcement Administration (DEA) registration numbers, driver’s license numbers, passport numbers, social security numbers and other personally identifiable information. They then extorted victims by threatening to publish data online.” Moucka also threatened and harassed government officials and security researchers who were helping to track him down. The Justice Department said the conspirators made over $2.5 million in ransom payments, and that in at least one instance, Moucka re-extorted a victim with threats of further disclosure of the victim’s stolen data. “Moucka used the stolen data of a government officer and members of a then-former government officer’s immediate family in this re-extortion attempt,” reads a statement from the Justice Department. One of Moucka’s admitted co-conspirators is Cameron “Kiberphant0m” Wagenius , a U.S. Army soldier who pleaded guilty in July 2025 to extorting AT&T and Verizon for their customer account data. Less than a month before Wagenius’s arrest, KrebsOnSecurity published a deep dive into Kiberphant0m’s various Telegram and Discord identities over the years, revealing how the owner of the accounts told others they were in the Army and stationed in South Korea. One of several selfies on the Facebook page of Cameron Wagenius. Kiberphant0m also re-extorted victims. Immediately following Moucka’s arrest, Kiberphant0m posted on hacker forums what he claimed were the AT&T call logs for then President-elect Donald Trump and for then Vice President Kamala Harris, as well schematics allegedly stolen from the U.S. National Security Agency (NSA). Wagenius is set to be sentenced on September 3, 2026. The government says he faces a maxim…

A Canadian man pleaded guilty today to his role in accessing company accounts at cloud storage provider Snowflake and stealing data from at least 165 organizations in a scheme to extort millions of dollars from victims. [...]

Incorrect authorization in the aggregation pipeline tool in Amazon AWS Labs DocumentDB MCP Server before 1.0.12 might allow an authenticated MCP client to perform inappropriate write operations on the connected database via write-capable aggregation pipeline stages that bypass the read-only mode enforcement logic. To remediate this issue, users should upgrade to version 1.0.12 or later.

Improper limitation of a pathname to a restricted directory in the get_resource tool in Amazon awslabs.aws-transform-mcp-server 0.1.0 through 0.1.4 might allow a context-dependent actor to write arbitrary files outside the intended working directory via the savePath parameter. To remediate this issue, users should upgrade to version 0.1.5 or later.

The calculus of cybersecurity has changed. AI is reshaping how organizations build, deploy, operate, and defend digital systems. AI-powered development tools, agents, and autonomous workflows are accelerating innovation but they are also introducing new attack surfaces, new trust boundaries, and new security challenges. Microsoft has long helped organizations secure their digital estates using Zero Trust principles . That leadership was recently recognized by KuppingerCole analysts, which named Microsoft as the Overall Leader in its Zero Trust Platform Leadership Compass , ranking Microsoft highest for both product and innovation leadership. Learn more about Zero Trust for AI As organizations accelerate AI adoption, secure software development becomes more important than ever. That’s why we are expanding the Zero Trust for AI strategy with two major additions: a new AI-focused Zero Trust Assessment experience and a new DevSecOps pillar in the Zero Trust Workshop . Together, they help organizations get ready for AI by assessing exposure, risks, prioritizing remediation, and securing AI-enabled development from source code to deployment. Zero Trust Assessment tool updates: New set of assessment checks for AI, Security Operations (SecOps), and Infrastructure. Zero Trust Workshop updates: New dedicated pillar focused on Developer Security (DevSecOps) and additional guidance for AI Memory. New guidance: New practical guidance for security practitioners and a new e-book titled Zero Trust for AI, rebuilding security controls for autonomous and agentic systems . This builds directly on the Zero Trust for AI strategy announced at RSA Conference 2026 and moves the conversation from architecture to implementation. If that announcement was about establishing Zero Trust for AI, this one is about operationalizing it: giving security, engineering, and platform teams the specific controls they need to act. To learn more about our work in applying Zero Trust for AI and agents watch this Microsoft Mechanics video: New AI pillar in Zero Trust Assessment tool The Zero Trust Assessment provides an automated view of security posture by evaluating tenant configuration and activity signals across the environment and translating those findings into prioritized recommendations. As organizations adopt AI agents, Copilots, developer tools, and autonomous workflows, the Assessment helps security and platform teams establish a baseline, measure progress, and identify gaps across both traditional and AI-powered environments. It now includes expanded coverage with new pillars for AI, Security Operations, and Infrastructure (in addition to existing Identity, Devices, Network, and Data pillars), with Zero Trust for AI-focused checks that help organizations evaluate the controls required for secure AI adoption. Additionally, enhanced reporting delivers both practitioner-level guidance and executive-ready summaries that communicate risk, progress, and next steps. Results map directly into the Zero Trust Workshop’s First, Then, Next framework, transforming assessment findings into a prioritized roadmap for remediation and implementation. Together, the Assessment and Workshop help organizations move from understanding risk to executing a structured plan for continuous improvement across their Zero Trust and AI security journey. Explore the Zero Trust Assessment updates What’s New in the Zero Trust Workshop AI is fundamentally changing software development. Developers increasingly rely on AI assistants to generate code, recommend packages, create infrastructure configurations, and automate testing. While these capabilities accelerate delivery, they also amplify the consequences of governance gaps, excessive permissions, insecure dependencies, and compromised supply chains. That is why Microsoft is introducing a new DevSecOps pillar (with 15 control groups and 91 tasks that help teams apply Zero Trust from source code to cloud deployment) in the Zero Trust Workshop.…

In this article Attack chain overview Mitigation and protection guidance Indicators of compromise (IOC) Microsoft Defender XDR detections Advanced hunting queries Learn more Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others. The malicious releases contain a Mini Shai-Hulud variant, a self-propagating credential-stealing worm delivered through a large, heavily obfuscated Bun-based JavaScript payload. The malware typically executes automatically through an npm preinstall lifecycle hook before package installation completes. Once executed, the malware searches developer workstations and continuous integration and continuous delivery (CI/CD) environments for npm, GitHub, cloud, and infrastructure credentials. It uses recovered identities to authenticate to npm, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault, enabling it to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. Collected data is encrypted and transmitted through an attacker-controlled HTTPS endpoint, with GitHub repositories serving as a fallback exfiltration channel. The payload’s most significant capability is automated propagation. After obtaining an npm publishing token, it enumerates packages available to the compromised identity, downloads their latest tarballs, inserts the malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. The malware can also use stolen GitHub credentials to inject Claude and Visual Studio Code configuration files into repositories, establishing persistence and creating an additional developer-to-developer infection path. In this blog, we’re sharing our analysis of this supply chain attack, along with protection, detection, amd hunting guidance. Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised. Investigations should prioritize credentials accessible to the affected identity, unauthorized npm releases, unexpected repository or workflow modifications, suspicious cloud and secret-store access, and artifacts produced by affected build systems. Organizations should revoke and rotate exposed credentials from a known-clean environment and rebuild affected systems and downstream artifacts from trusted sources. Attack chain overview The campaign appeared as a rapid sequence of unauthorized patch releases across more than 400 npm packages maintained by otherwise unrelated publishers. Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release, indicating that the attackers modified and published package tarballs directly rather than compromising each public source repository. Affected releases typically added a preinstall lifecycle script that launched a malicious file, setup.mjs, contained within the package, which launched the large, obfuscated Bun JavaScript bundle included in the package. Because npm runs preinstall scripts before installation completes, the payload could execute on developer workstations and build runners before application tests or conventional security checks began. After execution, the malware performs the following actions: Determines whether it is running on a developer workstation or in a CI/CD environment. On workstations, it detaches itself to continue after installation; on CI/CD systems, it remains in the active job to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions. Both paths could support further package or repository propagation when suitable credentials are found. Collects credentials from local files, environment variables, command-line tools, and GitHub A…

As organizations adopt AI, they must secure both cloud and AI environments through a unified security control plane as their attack surface expands. Because modern applications and AI workloads are built and run in the cloud, security teams must understand which exposures matter most, prioritize what can truly be exploited, and reduce risk across cloud infrastructure, applications, identities, data, and AI systems in one place. Modern IT estates now span multiple clouds and on-premises systems, with architectures built on containers, Kubernetes, serverless functions, microservices, APIs, and AI-powered workloads. This increases both the volume and the interconnectedness of security signals. The challenge is no longer identifying individual risks, but determining how misconfigurations, identities, and data exposures combine to create real attack paths, and which of these are most critical to fix at the source. KuppingerCole’s Leadership Compass: Cloud Native Application Protection Platforms (CNAPP) reflects this shift. The report describes how CNAPP is evolving from a consolidation of cloud security tools into the security foundation for AI-native enterprises, combining cloud security, AI security posture management, runtime protection, attack path analysis, cloud detection and response, and agentic AI operations into unified platforms. Read the full report Within this evolving market, KuppingerCole names Microsoft a Leader across all four of its Leadership categories: Overall, Product, Innovation, and Market. In the report’s words: “Microsoft earns its Overall Leadership with its Defender for Cloud that is redefining the CNAPP market by extending cloud security beyond infrastructure protection and into a unified security platform for cloud, data, identity, AI, and security operations, supported by one of the industry’s most advanced agentic AI ecosystems.” That recognition reflects where the category is heading: toward platforms that unify cloud and AI security into one operational view of risk. Why CNAPP is being redefined KuppingerCole makes a clear point: CNAPP is no longer about posture or visibility alone. It is becoming the operational foundation for securing AI-powered applications, services, and business processes, across the full software lifecycle from cloud infrastructure to the AI systems running on top of it. Modern environments introduce complexity across: Multicloud and hybrid infrastructure. Rapid development and continuous deployment. Containers, serverless, microservices, and APIs. AI models, agents, pipelines, and machine identities. This complexity exposes the limits of traditional, siloed tools, where cloud posture, workload protection, AI security, and the security operations center (SOC) each live in their own console. Organizations now need platforms that can: Correlate posture, runtime, identity, data, application, and AI signals. Prioritize risk based on exploitability, not severity alone. Integrate security across development, cloud operations, and the SOC. Bring AI systems into the same risk model as the rest of the cloud. Runtime intelligence is now central to this shift. Across the platforms KuppingerCole evaluated, 94% detect active exploitation of the complex attack paths they surface, moving teams from long lists of findings to the exposures threat actors can actually use. What distinguishes leading platforms KuppingerCole evaluates providers on product strength, innovation, and market presence, and, more importantly, on how effectively they help organizations manage real risk across cloud and AI. Several themes define the next generation of platforms: AI security posture management that governs models, pipelines, and AI-specific attack paths. Agentic AI that investigates, validates exposures, and helps remediate, not just detect. Runtime-driven risk prioritization focused on what is exploitable in production. Security graphs and attack path analysis across identity, data, network, workload, an…

When you learn that a compromised package executed on one of your build hosts, muscle memory takes over: revoke the npm token, rotate the GitHub PAT, cycle the cloud keys. That reflex has been correct in almost every supply-chain incident I have worked. In the keyv/cacheable compromise that has been unfolding since yesterday, it is the one thing you should not do first — because revoking the stolen token is exactly what arms the payload.