Threats tagged 'kubernetes'

Dell has patched two maximum severity vulnerabilities in the Container Storage Modules (CSM) that connect Dell enterprise storage arrays to Kubernetes environments. [...]

Improper neutralization of argument delimiters in the volume handling component in AWS EFS CSI Driver (aws-efs-csi-driver) v3.1.0 through v3.4.2 might allow remote authenticated users with PersistentVolume creation permissions to inject arbitrary mount options via comma-separated values in the mounttargetipmap volumeAttribute. To remediate this issue, users should upgrade to version v3.5.0 or later.

OperTraitor is an open-source tool designed to audit Kubernetes operators for excessive RBAC privileges, identifying risks from overly permissive service accounts. Kubernetes operators automate cluster management but often run with broad permissions, creating security weak spots that can be exploited if compromised. The tool compares an operator's documented functionality against its actual granted privileges, assigning a risk score to highlight potential threats. Research using OperTraitor uncovered a high-severity vulnerability (CVE-2026-6389) in IBM's Turbonomic platform and widespread issues with abandoned or overly permissive operators in OperatorHub. The rise of AI-driven agentic operators increases the risk, as autonomous operators with excessive permissions can cause greater damage. The analysis emphasizes securing service accounts and auditing operator permissions before deployment to mitigate these risks.

A security issue exists in Google Kubernetes Config Connector (KCC) where a Kubernetes user with limited permissions can escalate privileges to gain control over an entire Google Cloud organization. This occurs because KCC uses a single Google Cloud service account with broad permissions to perform actions on behalf of Kubernetes users, without verifying if the user is authorized for those actions in Google Cloud. This confused deputy problem allows a user who can create IAMPolicyMember resources in a Kubernetes namespace to assign themselves any Google Cloud IAM role that KCC's service account can grant, including organization owner. Google acknowledges this behavior as intended design, but it creates a significant risk if KCC's service account has overly broad permissions and Kubernetes RBAC is not tightly controlled.

Published: 2026-09-09 Reference: GHSA-p7v4-vr35-mj6f Description Severity A security vulnerability GHSA-p7v4-vr35-mj6f (CVE assignment pending) in containerd's CRI implementation allows a container restored from an untrusted checkpoint through the CreateContainer API to bypass the destination security context and execute with elevated privileges. When restoring a container from a checkpoint archive or annotated OCI image, CRIU restores process credentials, Linux capabilities, no_new_privs , and seccomp state directly from checkpoint data rather than enforcing the destination CRI ContainerConfig . An attacker who can run a container with a crafted checkpoint image can execute processes as the root user with full capabilities and no enforced seccomp filters despite restrictive security policies requested by the orchestrator. Additionally, containerd's CRI status reporting reflects the requested configuration rather than the actual restored process state, masking the privilege discrepancy from orchestrators. GKE clusters are not vulnerable by default. GKE node images do not include the criu tool. Implicit container restore is not supported without criu installed on the node. Standard container creation operations in GKE Standard and GKE Autopilot remain unaffected. GKE Autopilot clusters do not support custom runtime configuration and are not impacted. Additionally, Pod snapshots in GKE do not exercise the vulnerable implicit restore codepath. In updated containerd versions (2.3.4 and later, or 2.2.7 and later), implicit restore is disabled by default through the enable_experimental_restore_via_create configuration option. Version 2.4 of containerd will remove this codepath completely in favor of the explicit Pod-level restore API (KEP-5823). Warning: Administrators can manually re-enable the feature in containerd (2.3.4 and later, or 2.2.7 and later) by setting the enable_experimental_restore_via_create configuration option. However, doing so leaves this vulnerability present because containerd cannot enforce destination security policy while it restores the criu process. What should I do? Because GKE does not include the criu binary on default node images, no immediate cluster upgrades or configuration changes are required for default workloads. If you install custom runtime software or node tools on your nodes that include the criu binary, consider taking the following actions as appropriate for your environment: Re-create existing restored containers: Stop, delete, and re-create any running containers that were restored from untrusted checkpoints. Disable experimental restore (containerd 2.3.4 and later, or 2.2.7 and later): If operating nodes with containerd (2.3.4 and later, or 2.2.7 and later) and custom criu installations, ensure the enable_experimental_restore_via_create configuration option remains set to false in your containerd node configuration. Audit containerd logs: If criu is installed, inspect node logs for implicit restore log entries containing search strings such as "Found checkpoint of container" , "Prepared for restore" , or "Restored container successfully" . Monitor deprecation warnings for containerd: Look for the following deprecation warning event: io.containerd.deprecation/cri-create-container-checkpoint-restore . Restrict Pod creation permissions: Ensure Kubernetes RBAC restricts Pod creation permissions ( create pods ) strictly to trusted users and service accounts. Enforce trusted image registries: Ensure that the values for the Pod's image: field reference verified image repositories. Prepare for KEP-5823: Update operational procedures to rely on explicit Pod-level Checkpoint or Restore APIs after they are available in future Kubernetes releases. Medium

Bulletin ID: 2026-055-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 07/14/2026 13:30 PM PDT Description: The AWS Load Balancer Controller is an open-source Kubernetes controller that manages AWS Elastic Load Balancing resources for Kubernetes clusters. We identified CVE-2026-15738, an incorrect rule precedence ordering issue in the Gateway API listener rule generation logic. When both an HTTPRoute and a GRPCRoute are attached to the same Application Load Balancer (ALB) HTTPS listener with the same hostname, the controller assigns ALB listener rule priorities based on route kind rather than route specificity. This causes all HTTPRoute-derived rules to receive lower ALB priority numbers, evaluated first by the ALB, than GRPCRoute-derived rules, regardless of which route is more specific. A namespace-scoped user with permission to create HTTPRoute objects in a namespace admitted by a shared Gateway can create a catch-all HTTPRoute that intercepts traffic intended for a more-specific GRPCRoute in another namespace. Impacted versions: AWS Load Balancer Controller v3.4.1 and any version that includes support for attaching both HTTPRoute and GRPCRoute to the same listener (introduced in PR #4794) Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

This content is a security industry report highlighting Microsoft's recognition as a leader in the Frost Radar™: Cloud Workload Protection Platforms (CWPP) for 2026. It discusses the evolving challenges of protecting cloud workloads, especially in complex environments using containers and Kubernetes, and emphasizes the need for integrated runtime security solutions. Microsoft Defender for Cloud is noted for its comprehensive coverage and integration across infrastructure, workloads, identities, and applications. The report does not describe a specific vulnerability or exploit but rather industry trends and product capabilities.

Microsoft has released its monthly security update for August 2026, which includes 421 vulnerabilities affecting a range of products, including 62 that Microsoft marked as "critical." Microsoft notes that 1 of the vulnerabilities disclosed this month have been exploited in the wild CVE-2026-68820 is an elevation of privilege vulnerability affecting Windows Ancillary Function Driver for WinSock. A Use After Free vulnerability could allow an authorized attacker to elevate privileges locally. This vulnerability has a CVSS base score of 7.0. Out of 62 "critical" vulnerabilities, 40 are remote code execution (RCE) vulnerabilities. Microsoft considers exploitation of the following vulnerabilities more likely. CVE-2026-62893 is a remote code execution vulnerability affecting Windows Deployment Services TFTP Server. A Use After Free could allow an unauthorized attacker to execute code over a network. This vulnerability has a CVSS base score of 9.8. CVE-2026-65665 is a remote code execution vulnerability affecting Microsoft SharePoint Server. Deserialization of Untrusted Data could allow an authorized attacker to execute code over a network. This vulnerability has a CVSS base score of 8.8. CVE-2026-62823 is a remote code execution vulnerability affecting Windows DHCP Server. A Heap-based Buffer Overflow could allow an unauthorized attacker to execute code over an adjacent network. This vulnerability has a CVSS base score of 8.8. Microsoft considers exploitation of the following vulnerabilities less likely. CVE-2026-62830 is an elevation of privilege vulnerability affecting Azure SRE Agent. Missing Authorization could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.9. CVE-2026-50516 is an elevation of privilege vulnerability affecting Microsoft Azure Kubernetes Service. Missing Authentication for Critical Function could allow an unauthorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 9.4. Three remote code execution vulnerabilities, CVE-2026-68794 , CVE-2026-68816 and CVE-2026-68804 , affect Microsoft Excel and have a CVSS base score of 7.8. An unauthorized attacker could execute code locally. CVE-2026-68794 is a Heap-based Buffer Overflow. CVE-2026-68816 is a Stack-based Buffer Overflow. CVE-2026-68804 involves a Numeric Truncation Error and a Heap-based Buffer Overflow. CVE-2026-62911 is an elevation of privilege vulnerability affecting Microsoft Exchange Server. Authentication Bypass by Capture-replay could allow an authorized attacker to elevate privileges over a network. This vulnerability has a CVSS base score of 8.0. Nine remote code execution vulnerabilities, CVE-2026-63515 , CVE-2026-65657 , CVE-2026-63532 , CVE-2026-64898 , CVE-2026-64903 , CVE-2026-64909 , CVE-2026-64910 , CVE-2026-64911 and CVE-2026-70130 , affect Microsoft Office and could allow an unauthorized attacker to execute code locally. CVE-2026-63515 involves an Out-of-bounds Read and an Integer Underflow (Wrap or Wraparound) and has a CVSS base score of 7.8. CVE-2026-65657 is a Use After Free and has a CVSS base score of 7.8. CVE-2026-63532 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64898 involves a Heap-based Buffer Overflow and an Integer Overflow or Wraparound and has a CVSS base score of 7.8. CVE-2026-64903 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64909 involves an Integer Underflow (Wrap or Wraparound), an Out-of-bounds Read and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-64910 is an Untrusted Pointer Dereference and has a CVSS base score of 7.8. CVE-2026-64911 involves an Integer Overflow or Wraparound and a Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-70130 is a Heap-based Buffer Overflow and has a CVSS base score of 8.4. Five remote code exec…

A 710 KB JavaScript payload was discovered in the compromised keyv@6.0.0 package, representing a newer variant of Shai-Hulud with enhanced obfuscation techniques. The malicious code operates with four primary objectives: harvesting credentials from local systems, CI environments, cloud platforms, Kubernetes, and Vault; exfiltrating encrypted data through dynamic HTTPS endpoints or public GitHub repositories; leveraging stolen npm credentials to publish infected patch releases across accessible packages; and exploiting GitHub credentials with GitHub Actions to compromise repositories and extract additional credentials. The campaign demonstrates sophisticated supply chain attack capabilities, targeting the npm ecosystem and development infrastructure. Multiple components were identified including obfuscated JavaScript files, VS Code configuration files, and injected GitHub Actions workflows, indicating a comprehensive approach to credential theft and lateral movement across development environments.

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…

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…

Between May and July 2026, security researchers deployed an unauthenticated Model Context Protocol (MCP) honeypot server to observe how threat actors exploit AI agent infrastructure. Of approximately 1,000 sources that reached the decoy, 596 spoke the protocol and 24 proceeded to actively exploit it. These operators executed 628 shell commands, 255 file reads, and 248 secrets-store lookups, with 19 hunting credentials and 4 attempting container escapes. Activity escalated from 39 tool calls in May to 877 by mid-July. Three stolen credentials were subsequently used against a live AWS account, with two cases involving Bedrock model invocation for LLMjacking. The attacks demonstrated automated reconnaissance, credential harvesting, container escape attempts, backdoor account creation, and Kubernetes enumeration, revealing that exposed MCP servers represent a growing attack surface as AI agent infrastructure proliferates.

Bulletin ID: 2026-046-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 06/18/2026 17:30 PM PDT Description: containerd is an open-source container runtime used by Kubernetes via the Container Runtime Interface (CRI) plugin. It underpins AWS managed container services including Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), AWS Fargate, Bottlerocket, and Amazon Linux. AWS identified five issues in the containerd CRI plugin affecting versions 1.7 through 2.3. - CVE-2026-50195 (GHSA-cvxm-645q-p574) - CRI checkpoint import, local image tag poisoning - CVE-2026-53488 (GHSA-xhf5-7wjv-pqxp) - image-config LABEL -> host-root command exec - CVE-2026-53492 (GHSA-33vj-92qq-66hc) - CDI annotation smuggling during checkpoint restore - CVE-2026-53489 (GHSA-rgh6-rfwx-v388) - arbitrary host file read via symlink in checkpoint restore - CVE-2026-47262 (GHSA-jpcc-p29g-p8mq) - image-triggered runtime DoS Impacted versions: containerd 1.7, 2.0, 2.1, 2.2, 2.3 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

TeamPCP uploaded malicious versions of the telnyx Python SDK to PyPI, compromising a package with 750,000 monthly downloads. The attack uses a three-stage architecture: a trojanized package triggers a platform-specific loader, which downloads a second-stage payload hidden in a WAV file using steganography, deploying a credential harvester. The harvester steals various credentials, encrypts them, and exfiltrates to the attacker's C2. The attack works across major operating systems and spreads through Kubernetes clusters. This is part of a broader TeamPCP supply chain campaign that has targeted multiple packages over nine days. The sophisticated attack includes WAV and PNG steganography, hybrid encryption, Kubernetes lateral movement, and a full-featured RAT on Windows with advanced evasion techniques.

A supply chain poisoning attack on LiteLLM, a popular AI model gateway, was detected by NSFOCUS Technology CERT. The TeamPCP group compromised the Trivy security scanning tool used in LiteLLM's release process, allowing them to publish malicious versions 1.82.7 and 1.82.8 on PyPI. These versions contained credential-stealing programs that collected sensitive data and, if a Kubernetes cluster was detected, deployed privileged Pods and implanted persistent backdoors. The attack impacted numerous dependent packages and potentially affected millions of users. The incident highlights the growing risks in AI infrastructure and the need for robust supply chain security measures.

Campaign#software security#supply chain attackUnited States+9

A new payload in the TeamPCP arsenal has been discovered, capable of wiping entire Kubernetes clusters. The script uses the same ICP canister as the CanisterWorm campaign, with consistent lateral movement via DaemonSets. However, this variant introduces a geopolitically targeted destructive payload aimed specifically at Iranian systems. The malware checks timezone and locale to identify Iranian systems, deploying privileged DaemonSets across every node in Kubernetes environments. Iranian nodes are wiped and force-rebooted, while non-Iranian nodes receive the CanisterWorm backdoor. The latest variant adds network-based lateral movement, exploiting exposed Docker APIs and using SSH for spread. This development shows TeamPCP's ability to operate at supply chain scale and their willingness to engage in destructive actions.

Malware#docker api#canisterwormIran+9