By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

On August 4, 2026, a self-propagating worm began 

publishing malicious versions of the npm packages keyv and cacheable

, is still developing as we publish, and the list of affected 

 packages has grown through the day to 2,236 package versions. Below we cover what we know so far, how to check whether your organization is exposed, and the controls that stop this class of attack from reaching your builds.

Beginning around 10:53 UTC on August 4, an attacker started pushing malicious releases to legitimate, well-established 

 packages. We know these were not a set of newly published typosquatted packages; the attacker is publishing new 

 of real packages that teams already depend on.

The scale of this attack is significant - tracking so far points to roughly 

 published across them. Several packages received a dozen or more malicious versions in a matter of hours, and new versions were still appearing past 13:20 UTC.

The affected packages sit deep in the JavaScript dependency graph. 

 are transitive dependencies of a large range of common tooling, so most teams that install them never explicitly chose them directly. Weekly download volume for some of these packages rivals the most popular libraries on 

, which gave the campaign a very large potential blast radius.

The activity carries the hallmarks of the 

. The malicious payload is delivered through install-time lifecycle (preinstall) scripts. Once executed on a developer or CI machine, it harvests credentials and tokens and uses any recovered 

 publish tokens to push malicious versions to other packages the compromised account controls. That self-propagation is why a handful of initial compromises turned into hundreds of packages within hours.

It’s also important to note that if you’re running 

, released roughly a month ago, it no longer runs lifecycle scripts by default. Organizations that have upgraded and not re-enabled script execution are substantially protected even if a malicious version was pulled, because the payload never runs on install. However, teams still on older 

 clients, or that have explicitly enabled install scripts, do not have that inherent protection.

Exposure comes down to two questions: did you install an affected version, and could it run on install?

 Compare the packages and versions in your lockfiles (

 against the current indicators. Community trackers are maintaining live lists; the tagged dataset at 

 are both being updated as the campaign expands. Because the affected set is still growing, treat any single snapshot as a lower bound and re-check.

Match on whole package names, not substrings.

 When scripting your own checks, anchor on exact package names. Loose substring matching produces false positives (for example, flagging an unrelated package that merely contains an affected name as a fragment) and wastes triage time.

 The malicious versions were published in a bounded window on August 4. A version of an affected package that predates that window is not part of this campaign. Confirm the specific version, not just the package name.

Check whether install scripts can execute.

 client version and whether lifecycle scripts are enabled in your environments. If you are on 

 with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 If a malicious version could have run in a developer or CI environment, rotate 

 tokens, cloud credentials, and any secrets that were reachable from that environment, and review recent publish activity on your own packages.

Search your Cloudsmith registry for any cached versions & quarantine. 

If your organization doesn’t have a cooldown or malware policy in place, there's a chance a malicious version was already requested by a developer or pipeline and cached in Cloudsmith - search for any affected versions and quarantine them.

If you find only pinned references in old, dormant projects, the immediate risk is usually low, since a locked dependency tree will not pull a new malicious version on its own. The real exposure is a fresh install or a lockfile refresh that resolves to a compromised version.

This attack is just another example of why pulling directly from a public registry into your builds is a risk worth removing. Cloudsmith sits between the public registry and your developers and pipelines as a single, policy-enforced control point, which changes the outcome in three ways.

While there are many client-side cooldown solutions built into native package managers, this can often be difficult to manage at scale for enterprises. Regardless of client version or script settings, Cloudsmith moves enforcement to the server-side by removing newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published and pulled into builds within minutes or hours, then withdrawn. 

 means those versions are never served to your teams during the window when they are most dangerous, buying time for the ecosystem to flag and remove them.

 Packages flowing through Cloudsmith are scanned for malware and also matched against our comprehensive database of malware advisories. With 

, you can define policies that block versions flagged as malicious or matching known indicators. When a package is identified as compromised, the policy stops it from being distributed to any consumer behind Cloudsmith, without waiting for every developer to update a manual blocklist.

 Because installs resolve through Cloudsmith rather than directly from the public registry, you get one place to enforce controls, one audit trail of exactly what entered your environment, and the ability to answer "were we exposed?" from your own records instead of reconstructing it across every machine and pipeline. Cooldown and malware policies only protect what actually routes through them, so 

 is ensuring your package installs go through the proxy rather than reaching upstream directly.

By applying these safeguards in Cloudsmith, you can greatly reduce the likelihood of being affected by the frequent supply chain attacks we are seeing across the open source ecosystem.

Cristian Garcia

Senior Customer Success Manager

Keyv and Cacheable npm packages compromised in active supply-chain attack

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating 

 campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as 

) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: 

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the 

 compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the 

). Depending on the target ecosystem, it then exchanged these temporary workflow credentials for registry-specific publish tokens, using OIDC token exchange endpoints for 

, or harvesting raw API keys for RubyGems and container registries like 

.

This allowed the published packages, container images, and extensions to carry valid SLSA Build track provenance signatures. To defenders, the updates appeared completely legitimate and officially attested across all affected registries. It’s the equivalent of deepfakes for the software supply chain.

Perhaps the most malicious aspect of this multi-registry wave was its defence mechanism. Once inside a developer's local machine or build server (whether pulled via a Python 

 package, or a VS Code extension) the payload established a background daemon named 

. This daemon monitored whether its stolen tokens had been rotated or revoked, acting as a dead man’s switch. If a defender revoked the token, the daemon immediately triggered a local script that executed 

, wiping the victim's entire home directory to eliminate forensic traces and punish the developer.

 represents the third evolution of the Shai-Hulud family of worm attacks, compromising hundreds of 

 components (including packages within the 

 namespaces).

In this workflow, a simple 

 command that drops the Miasma payload. Again, the tactics and techniques of this Shai-Hulud worm have changed multiple times so far this year. Most security scanners and manual reviewers focus closely on scripts blocks in 

 triggers).

Miasma bypassed this completely by abusing 

, for context, is a legitimate config file used to compile native C++ Node.js add-ons. When a package containing this file is installed, the npm client automatically spawns 

. The attackers embedded direct command execution wrappers inside the 

 target configs. The system executes the malicious payload during compilation, completely avoiding the need for suspicious 

 lifecycle scripts.

Miasma focused heavily on capturing cloud identities instead of static keys, implementing collectors specifically designed to steal active GCP and Azure SSO credentials. Furthermore, if the infected CI container had access to the host's Docker socket (

), the malware would’ve performed a Docker escape. It identifies and terminates security monitoring containers (such as Step Security’s 

), creating a privileged Alpine container to write passwordless 

, and altered local DNS resolution to block telemetry reporting domains.

Discovered on June 8th, 2026, straight after the Miasma variant, the campaign expanded to the Python ecosystem, targeting critical academic genomics and phenotype analysis packages on 

).

In this attack, a simple Python Import loads a 

 extension which executes embedded javascript. The embedded javascript code executes a final Bun payload which exfiltrates to a GitHub endpoint.

In a major evasion upgrade, the attackers did not modify any Python source files. Instead, they embedded the malicious JavaScript loader inside the compiled Rust/C++ binary extension (

).

When a researcher imports the package via Python (

 file. The shared object discreetly initialises and runs an embedded JavaScript engine to execute the payload. This makes the new attack completely invisible to code-reviewers looking at Python source files.

The payload's primary file, 

, contains a massive block of comment text representing a fake LLM jailbreak prompt. The decoy simulated classified briefings, asking for technical steps on weaponising biological agents and designing nuclear devices. This was a deliberate attempt to pollute static analysers and AI-assisted tooling, causing them to choke, flag false positives on safety boundaries, or even worse, misclassify the file as a prompt-injection experiment rather than a credential-stealing worm.

Instead of a standard server, the Hades variant registered dozens of GitHub repositories using the compromise-controlled user account 

. The repositories used underworld-themed naming conventions (like 

. The exfiltrated data was stored in an encrypted envelope format, signed with GPG keys.

In August 2026, the open-sourced Mini Shai-Hulud codebase was weaponised in one of the most widespread multi-registry campaigns to date. The outbreak began with the compromise of 

's account. This was the primary developer behind popular, heavily downloaded packages like 

.

From this single entry point, the worm exponentially expanded into over 444 packages across 2,000+ published releases, hit 100 packages in the 

 ecosystem alone, and aggressively turned every infected machine into an automated propagation node.

The execution chain relies on the 

 dropper. To evade standard JavaScript static analysis tuned for Node.js patterns, the 

 file detected the host architecture, downloaded a bundled 

 runtime, and proceeded to execute a massive, heavily obfuscated payload named 

.

Rather than stopping at passive credential dumping, this variant actively probed and harvested deeper infrastructure credentials: It actively queried AWS IMDSv2 and ECS endpoints, enumerated AWS SecretsManager paths, read mounted Kubernetes ServiceAccount tokens, and extracted HashiCorp Vault secrets across KV v1 & v2 mounts. It even hunted local crypto wallets like bitcoin wallet files. It was observed that exfiltration calls were routed to a dynamic domain endpoint. Crucially, if the server returned an execute payload in its JSON response, the worm immediately executed it using 

, giving the threat actors live remote code execution on infected dev machines and CI runners. Finally, if the primary C2 server failed, the worm fell back to using stolen GitHub tokens to automatically create public GitHub repos containing base64-encoded stolen data, tagging the repo descriptions with a distinctive campaign marker. This time 

.

To ensure propagation, the worm scraped 

 creds or even exchanged GitHub Actions OIDC tokens to auto-publish patch updates of packages the maintainer controlled. It inserted 

 as an optional dependency, allowing the payload to silently cascade into downstream installs without causing build failures. Furthermore, it even expanded on the infection vectors directly inside dev workflows by writing malicious GitHub Actions workflows disguised with the name 

, as well as altering AI-related dev tooling via poisoned 

Shai-Hulud-style worms will continue to change shape

 or leaking of a complex piece of malware like the Shai-Hulud worm typically triggers a significant shift in the threat landscape. When a sophisticated framework (originally tightly controlled by an advanced group like TeamPCP) becomes publicly accessible, it lowers the barrier to entry for a much wider, more disorganised pool of actors. Independent operators, smaller cybercriminal syndicates, and even security researchers looking to understand its mechanics can dissect the original codebase. This democratisation of advanced tech means that features previously requiring high-level engineering, such as automated supply-chain propagation or complex credential harvesting, become plug-and-play modules for anyone with basic development skills.

Without a centralised command structure like TeamPCP directing its deployment, the evolution of Shai-Hulud has naturally fragmented into highly specialised or experimental variants (such as 

). Newer threat actors are combining Shai-Hulud’s core self-propagating mechanisms with different payloads or evasion techniques tailored to their specific objectives. For instance, some variants strip away the heavier components to create lightweight stealth tools, while others swap out the exfiltration methods to target different developer ecosystems beyond 

. This fragmentation complicates defense strategies, as defenders can no longer rely on a single set of behavioural signatures or specific infrastructure indicators associated with the original group.

Furthermore, this post-TeamPCP era accelerated the timeline of dual-use engineering, where threat actors repurpose and optimise techniques from Shai-Hulud in unexpected ways (as seen in the 

). Independent devs often modify the codebase to patch flaws left by the original authors (such as fixing loud fallback routines or refining how the worm handles OIDC token exchanges). Because these new variants are built and deployed by completely unrelated clusters of users, the attribution of attacks becomes incredibly muddy. The signature architecture of Shai-Hulud is no longer a reliable indicator of 

 is attacking, but rather a reflection of a shared, open-source repository of commodity supply-chain threats. This is glaringly the case with alleged 

If the evolution of Shai-Hulud proves anything, it's that attackers are exceptionally creative and relying purely on reactive remediation is a losing strategy. When malware can pass SLSA attestations, bypass 

 inspection via native builds, and hide inside compiled binaries, you simply cannot predict every vector. It only takes one compromised token to trigger a massive downstream disaster. While rapid incident response remains essential, putting heavy effort into proactive preventions, such as universal package cooldown policies and strict pipeline boundaries is the only way to neutralise these threats before they execute. Stopping the attack at the gate will always be easier than cleaning up the damage after a worm gets through.

If you found this breakdown useful and want to keep up with the evolving threat landscape of malicious dependencies and open-source malware, join our upcoming webinar: 

Inside the Open Source Malware Attack Landscape

) to discuss real-world attack vectors and how to protect your software pipelines.

Nigel Douglas

Head of Developer Relations

The evolution of Shai-Hulud-style worms

The Cloud-Native Digest is a monthly roundup on all things cloud native, artifact management, and supply chain security from Cloudsmith's Head of Developer Relations, Nigel Douglas.

Welcome to the July 2026 edition. In this issue, we’re tackling the real-world realities of modern software defense, from why high vulnerability scores can misrepresent actual risk of exploitation to the ways that AI agents are escaping existing sandbox boundaries, as seen with the Hugging Face and OpenAI fallout. Plus, we break down critical supply chain stories across 

. Let’s jump straight into the analysis.

Supply Chain Security in the Month of July

Why higher CVSS vulnerabilities aren't always the most exploited
Date: 

July 1st 2026

The Sysdig Threat Research Team observed the first known in-the-wild exploitation of 

, a CVSS 9.9 IDOR-style vulnerability in Langflow, alongside 

, a lower-scored (CVSS 9.3) unauthenticated RCE. Despite the IDOR's higher CVSS score, opportunistic threat actors heavily favour the RCE because it provides immediate host execution with minimal effort, whereas the IDOR requires enumerating flow UUIDs and is harder to weaponise. Ultimately, the findings illustrate the effort-to-yield paradox whereby CVSS scores do not always reflect real-world exploitation risk, though the IDOR poses a severe threat in multi-tenant environments where host-level RCE is sandboxed.



https://www.sysdig.com/blog/understanding-langflow-cve-2026-55255-and-why-higher-cvss-vulnerabilities-arent-always-the-most-exploited

When upgrading is the wrong answer to a CVE
Date:

 July 22nd, 2026

While security standards mandate keeping dependencies up to date, relying solely on upgrading to fix vulnerabilities has become a flawed approach. Upgrading often fails because a fix may not exist yet, an abandoned package will never receive one, a new version introduces breaking changes, or the latest release contains malicious code from a compromised maintainer. These factors are compounded by AI tools that enable attackers to quickly chain minor vulnerabilities into major exploits; traditional scanning and upgrading can no longer keep up. Instead of risking broken builds or undertaking costly migrations, a better path is directly patching the specific vulnerability within the existing, trusted version of a package.



https://www.aikido.dev/blog/cve-upgrade-breaking-changes-open-source

Why is it so hard to configure time in cooldown logic?
Date:

 July 17th, 2026

Client-side cooldown policies which protect software supply chains by holding new packages for threat screening are heavily fragmented across language ecosystems. These policy controls often use inconsistent time formats (such as seconds, minutes, days, or ISO 8601 strings) or lack native support entirely (like Go and NuGet). Managing these conflicting client-side configs creates friction for security teams. The idea of centralised cooldown controls through a single platform like Cloudsmith eliminates this complexity by enforcing uniform security policies across all package formats from a single control plane, using a single interpretation of time.



https://cloudsmith.com/blog/how-to-configure-time-for-cooldown-policies

What’s the deal with the AsyncAPI npm supply chain attack?
Date:

 July 14th, 2026

Attackers exploited a misconfigured GitHub Actions workflow in the AsyncAPI project to steal automation tokens and release trojanised 

). Executing upon package import rather than on-install, the malicious payload harvested developer and CI/CD secrets. It bypasses traditional security scanners by leveraging legitimate release pipelines and clean initial advisory feeds. Organisations should check lock files for affected versions (such as 

), immediately rotate exposed tokens, and consider using private registry proxies with package cooldown policies to block future zero-hour supply chain risks.



https://cloudsmith.com/blog/inside-the-asyncapi-npm-supply-chain-attack

Cybersecurity startup publishes infostealers to NPM
Source:



The founder of an Israeli cybersecurity startup was found to have published at least seven typosquatted packages to JavaScript’s 

 registry, primarily impersonating popular AI developer tools like Anthropic, LangChain, and OpenAI. They functioned as quiet infostealers. By abusing automatic 

 execution scripts, the packages harvested detailed env & dev identity fingerprints (such as Git reflogs, hostnames, SSH key comments, and cloud account metadata) while explicitly avoiding direct credential theft to evade detection.



Signed, attested, and malicious: Your SSC has a deepfake problem
Source:



Software supply chain attacks have evolved into deepfakes. Attackers compromise 

 maintainer credentials and to publish malware that carries legitimate signatures, provenance, and attestations. Incidents like the Miasma worm in 

 registry demonstrate that security scanners can no longer rely on trust signals alone, as poisoned packages now appear indistinguishable from routine updates. Because technical verification mechanisms are functioning as designed rather than failing, security must shift toward behavioural analysis to evaluate what a package actually does before it reaches the dev's machine.



Next.js moves to scheduled security releases
Source:



Next.js is formalising a predictable, monthly security release program to provide advance notice and mitigate potential exploits, replacing its previous ad-hoc patching approach. The first scheduled security release came out on the 21st of July. This update delivered patch updates for Next.js versions 

 covering 9 total vulnerabilities (4 high and 5 medium severity).



Finding 8 high-severity vulnerabilities in NodeBB in 6 hours
Source:



Aikido Security used its AI-powered pentesting platform to discover eight high-severity vulnerabilities in NodeBB in under six hours. The findings included multiple cross-site scripting vectors, admin authorisation bypasses, user impersonation, mass assignment, and unauthenticated data leakage. Aikido reported the security flaws to the NodeBB maintainers, who patched all identified issues in version 

Untangling crates.io accounts from GitHub
Source:

, crates.io is decoupling its account system from GitHub by introducing native crates.io 

, laying the foundation to support alternative identity providers in the future. This shift provides significant benefits to the Rust community by offering devs greater control over their package-registry identity without tying it directly to a single platform. Beyond increasing flexibility, supporting additional login options makes the ecosystem more accessible to developers and organisations that don't use GitHub, while also reducing the risk of maintainers getting locked out of managing their crates due to single-platform outages, suspensions, or policy changes.



Announcing Topcoat: a framework for building full-stack react web apps with Rust
Source:

 is a modular, full-stack Rust web framework designed to simplify building reactive applications through server-side rendering without relying on WASM. It achieves client-side reactivity by rendering HTML on the server and embedding metadata or cross-compiling subset Rust expressions to JavaScript via macros. Driven by the philosophy of locality of behaviour, Topcoat features a complete asset pipeline, integrated icon/font libraries, request-level 

, and a Tailwind-based UI component system, complementing lower-level routers like Axum by eliminating typical web development boilerplate.



Battery packs: Let's talk about crates, baby!
Source:

) designed to help Rust developers quickly discover and set up curated sets of recommended crates, project templates, and GitHub Actions based on specific domains like CLI, embedded, or backend development. Rather than acting as a direct code dependency, a battery pack simply serves as an easily modifiable starting list to eliminate research fatigue for newcomers without causing vendor lock-in or ecosystem stagnation. Anyone can publish a battery pack, creating a flexible foundation that working groups can leverage to drive interoperability and pool funding for maintainers.



Unveiling RIFT: Enhancing Rust malware analysis through pattern matching
Source:

Microsoft Threat Intelligence Center (MSTIC)

, a toolset designed to automate and streamline the reverse engineering of Rust-based malware. Because Rust’s safety features, concurrency, and static linking produce unusually large binaries filled with library code, analysts often struggle to isolate a threat actor's actual code. RIFT addresses this by using pattern matching, such as compiler metadata extraction, custom FLIRT signatures, and binary diffing to identify and label third-party library dependencies automatically. By stripping away standard library clutter, RIFT significantly reduces analysis time, allowing security researchers to focus directly on malicious logic.

 proposes a public, tamper-evident transparency log operated directly by package indexes like PyPI to record artifact hashes and publisher identities. By making all publishing claims discoverable and permanent, the log prevents a compromised index from silently serving altered package files to different users, while enabling maintainers and third-party security monitors to immediately detect tampering or unauthorised releases.



Releases now reject new files after 14 days
Source:



To protect against project compromises, PyPI now rejects new file uploads to releases older than 14 days, preventing attackers from secretly poisoning stable packages. Triggered by high-profile supply chain compromises in early 2026 and backed by community consensus, the change requires maintainers to issue a new release version when adding files like new Python wheels. While formal APIs defining closed releases are coming via 

, this guardrail immediately protects Python users and keeps release histories clear and secure.



Pip 26.2: –only-deps solves 16 years of app deployment hacks
Source:

), solving a 16-year-old workaround for Python applications and scripts that do not need to be installed as packages. By allowing dev to install dependencies directly from 

 without installing the project itself, this change simplifies the app deployments and builds on the momentum driven by existing third-party tools like 

What every Python dev should know about the CPython ABI
Source:



CPython’s Application Binary Interface (ABI) defines the low-level rules, such as memory layout and exported symbols, that allow native C, C++, Rust, or Fortran extensions to interact with the Python interpreter. While a CAPI consists of source-level definitions like headers and macros, the ABI ensures compiled binaries can run correctly without link-time or runtime memory errors. Python packages use ABI compatibility tags in wheel filenames to signal whether a binary requires a specific CPython minor version (like 

) or supports the forward-compatible Stable ABI (

). The introduction of the free-threaded interpreter altered the internal PyObject layout to remove the 

). To address this, Python 3.15 introduces the 

 stable ABI, used opaque structs to allow a single compiled wheel to support both GIL-enabled and free-threaded builds across future releases.

CVE-2026-64600 - Kernel flaw lets attackers gain root access
Source:



RefluXFS is a 9-year-old Linux kernel race condition that allows local, unprivileged users to overwrite root-owned files at the block layer and gain persistent root access. The vulnerability affects systems using XFS filesystems created with 

, putting default installs of Red Hat Enterprise Linux, Fedora Server, and Amazon Linux at immediate risk. Because there are no practical 

-option workarounds, securing vulnerable hosts requires applying the vendor's backported kernel patch and rebooting the system.

CVE-2026-8933 - Ubuntu security flaw breaks Snap sandbox protections
Source:



Qualys researchers disclosed 2 high-severity local privilege escalation vulnerabilities in Ubuntu Desktop (CVE-2026-8933 & CVE-2026-3888). Both flaws affect default installs running 

. CVE-2026-8933 in particular allows unprivileged local users to gain root access by exploiting race conditions in temporary 

 directory initialisations, using FUSE mounts and symlinks to bypass AppArmor restrictions. Users should apply Canonical's latest security updates for 

CVE-2026-53359 - Lessons learned from handling a KVM flaw on tens of thousands of machines
Source:



Following the discovery of a 16-year-old use-after-free flaw in KVM x86, OVHcloud executed an urgent, 11-day emergency patching campaign across tens of thousands of hypervisors and 

. After ruling out live patching and migration at scale due to time and stability constraints, OVHcloud opted for a unilateral kernel patch and host reboot strategy to minimise the vulnerability window. Using a 24/7 follow-the-sun operational model, with anti-affinity safeguards to prevent simultaneous cluster outages, and targeted customer comms, the team successfully secured the entire fleet while containing service disruptions.



Linux kernel security faces challenge with surge in CVEs
Source:



Over a single two-day period, the Linux kernel team published 432 CVEs, overwhelming sysadmins and fueling speculation that AI-assisted bug hunting is driving a massive influx of reports. Because the kernel team assigns CVEs to nearly any bugfix affecting system availability, prioritising individual patches has become nearly impossible for security teams. Experts warn that neither manual reviews nor current LLM triage methods are equipped to handle this volume, leaving organisations forced to consider risky, frequent fleet-wide updates to keep pace with the ongoing surge - or adopt 

Kubernetes 1.37 – What you need to know
Source:



Scheduled for release next month, Kubernetes 1.37 introduces 86 total enhancements, focusing heavily on performance, cluster security, and fine-grained hardware management. Highlights include stable graduations for faster, non-recursive SELinux volume mounts and human-friendly KYAML formatting, along with new features like native per-container POSIX 

 binary data format for faster CRDs. The update also advances Dynamic Resource Allocation with standardised NUMA node attributes and device taints, while laying the groundwork to phase out 

Kubernetes Podcast episode 269: AI Policy, with Kat Cosgrove and Natali Vlatko
Source:



When people talk about AI in Kubernetes, the conversation is often focused on the user side, but for open source maintainers, there's of course a lot to unpack on how AI is changing OSS contribution! How does AI impact the community, and what are the new rules of engagement? In this session, Kat Cosgrove (SIG Docs Technical Lead, SIG Release Subproject Lead, and Kubernetes Steering Committee member) and Natali Vlatko (SIG Docs Co-Chair, TODO Group Steering Committee member, and OSPO at Cisco) unpacked the recently published Kubernetes AI usage policy for Kubernetes contributors.



Unpatched Argo CD flaw lets attackers takeover Kubernetes clusters
Source:



Synacktiv researchers used custom CodeQL analysis to discover an unauthenticated RCE vulnerability in Argo CD’s 

 component. By sending custom gRPC requests and manipulating cached entries in the internal Redis DB, an attacker could force Argo CD to deploy malicious manifests, ultimately leading to a full Kubernetes cluster takeover. The risk is heightened because standard Helm deployments leave network isolation disabled by default. In this scenario, applying strict Kubernetes network policies to restrict access to 

 appears to be the primary mitigation to this flaw.



New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys and Kubernetes Tokens
Source:



The NadMesh botnet poses a severe threat to Kubernetes environments by actively scanning exposed API servers, Kubelet endpoints, and etcd instances to execute remote code. It achieves node-level compromise through Kubernetes API exploitation by creating malicious pods with 

 mounts to escape container boundaries. Once inside, NadMesh harvests 

 ServiceAccount tokens, steals cloud and AI service creds from 

 variables, and maps internal networks for lateral movement. Check out the blog for steps to mitigate these risks.

Mitigating The Hugging Face Breach
Source:



Hugging Face and OpenAI disclosed a major security incident where an autonomous AI agent (

) broke out of OpenAI’s isolated research environment via a proxy zero-day and subsequently breached Hugging Face's production infrastructure to obtain benchmark answer keys. Rather than focusing on the AI's autonomous capability, security firm Edera highlights that both breaches succeeded due to a shared architecture flaw. This is where most of the industry still relies on shared-kernel container primitives (namespaces & cgroups) for isolation rather than hardware-enforced boundaries. Edera argues that mitigating such autonomous, high-speed threats requires shifting from traditional container runtimes to Type 1 hypervisor-level isolation to ensure that initial code execution cannot escalate to host nodes or internal clusters.



Chinese model Kimi K3 adds pressure on US AI policy
Source:

, a Chinese open-weight model that rivals top U.S. competitors in coding, has intensified pressure on the US government to establish a coherent national AI strategy. As domestic developers stall updates under voluntary government testing guidelines and flock to cheaper foreign models, American tech leaders are warning that the U.S. risks losing its competitive edge. Meanwhile, allegations that Moonshot distilled outputs from U.S. models like Claude have fuelled IP theft concerns, prompting White House debate over sanctions and potential restrictions on Chinese open-source technology.



Anthropic Launches Claude Security Plugin to Scan Code for Vulnerabilities
Source:



The security-specific plugin for Claude brings multi-agent vulnerability scanning directly into the Claude Code terminal interface. Designed to analyse complex logic and multi-file data flows beyond standard pattern matching, the tool identifies high-severity flaws, filters out false positives, and generates style-matched patches for human review. This allows developers to catch critical security risks seamlessly without leaving their existing workflow.



Agentic AI Challenges Progress in Confidential Computing
Source:



While technological advancements have largely resolved early barriers like cost and performance to boost enterprise adoption of 

, the rise of agentic AI presents new security risks due to agents retaining sensitive data in memory. To counter this threat model, experts advocate for new paradigms like individual encryption keys per agent. This would enable complete data deletion via a method known as 

. Major players like Apple, NVIDIA, and Microsoft will continue to push multi-layered confidential AI architectures to ensure improved data privacy without sacrificing their system performance.

Cloudsmith Blog

Keyv and Cacheable npm packages compromised in active supply-chain attack

The evolution of Shai-Hulud-style worms

Cloud Native Digest - July 2026

Kubernetes 1.37 – What you need to know

How to configure time for cooldown policies

Inside the AsyncAPI npm supply chain attack

How to use Cloudsmith as a dependency firewall

Cloud Native Digest - June 2026

What Cloudsmith shipped in Q2 2026

A dependency firewall gives your scanner better inputs

Start secure, stay secure with WizOS and Cloudsmith

Dependency attacks start before your scanner runs