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

Two critical core PHP vulnerabilities, together known as PHP2Shell, were disclosed this week and emergency patches are available. The flaws sit in PHP itself, so any site, developer environment, or CI pipeline running an unpatched version of PHP is exposed.

This kind of vulnerability requires a fast patch. PHP comes into environments in lots of places - in base images, CI runners, developer containers, and open source package repositories. In this scenario, ideally you’ll want a single view of your dependencies, so you don’t have to do a search across fragmented tools.

When PHP hits an out-of-memory error, a flaw in how it handles memory lets an unauthenticated attacker run arbitrary commands or read sensitive data from server memory.

The flaws affect every PHP release from 5.4 through 8.5.11. 

PHP reported that they consider consider the risk highest for mod_php

. There is a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

See which PHP versions your teams pulled and stop affected versions from being used

Cloudsmith can be the source of truth for what packages came into your environment, by which users, and when. That gives you a clear picture of your exposure.

Search your Cloudsmith repositories and package logs for the affected PHP versions.

Patched versions are available, but 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP 8.1 and earlier are end of life and will not receive a fix.

Block critical vulnerabilities automatically: 

Set a vulnerability policy that blocks packages with critical vulnerabilities. It applies as soon as an advisory is published and protects you against future critical vulnerabilities.

 When new threat intelligence lands, Cloudsmith re-checks all existing packages in your Cloudsmith repositories against your policies automatically.

 with Cloudsmith for a custom assessment of your software supply chain.

Meghan McGowan

Product Marketing Manager

Critical PHP vulnerabilities in PHP2Shell expose web infrastructure to remote code execution

an attacker compromised the popular Python package LiteLLM

, publishing version 1.107.0 to PyPI and pushing trojanized images to Docker Hub and GitHub Container Registry (GHCR). This is the second time we’ve seen an attack on LiteLLM, the first in March 2026.

If your organization pulled or installed 

 on or after October 21, rotate your cloud credentials, SSH keys, browser sessions, and AI provider API keys immediately. The malicious release executed a credential stealer designed to exfiltrate secrets and query LiteLLM databases.

Here is what happened, how to check your environments for exposure, and how to block compromised packages automatically using Cloudsmith.

At 11:39 UTC on October 21, an attacker uploaded version 1.107.0 of LiteLLM to PyPI alongside compromised Docker tags (

). The compromise occurred when stolen GitHub CLI OAuth tokens were used to access maintainer accounts, override branch protections, and trigger a release pipeline pointing to a lookalike repository.

Upon installation or execution, the package injects files into the Python 

). These files execute automatically whenever the Python interpreter starts and deploy a credential stealer targeting:

 and IMDS metadata), GCP service account keys, Azure CLI tokens, SSH private keys, and GPG keys.

 Keys for OpenAI, Anthropic, Cohere, and other providers stored in environment variables or configuration files.

 Upstream credentials stored in local or remote LiteLLM PostgreSQL tables (

 Saved credentials and cookies from Chrome, Firefox, Edge, and Safari.

The payload encrypted harvested secrets via AES-256-CBC and sent them to an attacker-controlled endpoint (

). Active abuse was observed within hours, as attackers tested stolen AWS credentials against LLM foundation models.

Follow these steps to confirm exposure across your developer machines, repositories, and CI/CD runners:

Check for LiteLLM images pulled from Docker Hub or GHCR on October 21 (tags 

Search your Cloudsmith repositories with exact package names to avoid false positives 

(format:python) AND (name:^litellm$) AND (version:^1.107.0$)

Review your Cloudsmith client logs to identify which developer machines or build agents fetched version 

 Check this even if the search returns nothing. Upstreams set to proxy only serve packages without storing them, so those packages won’t show up in search.

Remove installations and rotate secrets: 

 ran in any environment, remove it immediately. Rotate all reachable AWS, GCP, Azure, and AI provider API keys, as well as SSH keys and database passwords. In Cloudsmith, quarantine the package rather than deleting it, so you keep the download history for your investigation

Why AI development is speeding up the attack lifecycle 

AI in the hand of attackers is compressing the supply chain lifecycle. Threat actors write malware faster, target AI tools directly, and reach pipelines through automated agents. 

Attackers use LLMs to build malware faster: 

 analysis noted strong indication of LLM–assisted code generation in the payload, allowing the attacker to iterate rapidly on multi-platform malware.

Packages like LiteLLM sit between applications and LLM providers. Compromise one and you reach upstream API keys, database credentials, and cloud infrastructure in a single step.

Agents install packages at machine speed: 

As engineering teams adopt autonomous AI coding tools and automated CI/CD pipelines, dependencies resolve faster than human review can keep up.

Block compromised packages automatically with Cloudsmith

Public registries supply most of your dependencies, and they serve the ecosystem well. But pulling straight from public registries into builds means a malicious version of a package can reach you minutes after it’s published. Cloudsmith sits between public registries like PyPI and your developers and pipelines, acting as a central control point that protects you in three ways

Many package managers have client-side cooldowns, but they are hard to manage at scale. Cloudsmith enforces the cooldown at the repository level, so they work regardless of client version or script settings, by holding back newly published upstream versions for a defined time window (typically a few days). Attacks like LiteLLM 1.107.0 depend on speed: a malicious version is published, it gets pulled into builds within minutes, and then it’s withdrawn from the public registry.

These policies act on public reports to the OSV malicious packages repository and other sources. Cloudsmith scans packages and matches them against our consolidated database of malware advisories. Cloudsmith 

 helps you block versions flagged as malicious, or matching known indicators. Once a package is identified as compromised, the policy keeps it from reaching any endpoint client, even after a cooldown policy window. This eliminates the need to maintain a manual blocklist.

Cloudsmith acts as the source of package dependencies for every developer, AI agent, and build pipeline across your company. As a central control plane that enforces controls, Cloudsmith produces a comprehensive audit trail of what entered your environment to answer questions like “Were we exposed?”.



If you'd like to understand your current exposure, 

LiteLLM 1.107.0 compromised on PyPI

 was compromised. This package has 18k downloads/week and the attack shares a lot in common with the 

August compromise of the "cacheable" and "keyv" packages

. If anything in your organization installed Tensorlake SDK 

 on or after October 8, 2026, treat the npm, GitHub, and cloud credentials on that machine as compromised, along with any AI coding tool configs. The malicious version ran a credential-stealing worm on install. Here’s how to check whether you’re affected, what to rotate, and how Cloudsmith helps keep versions like this out of your builds.

On October 8, an attacker published version 

 of the Tensorlake SDK, a package with about 18,000 weekly downloads. It contained two files that work together:

 runs through a preinstall hook and launches the payload using Bun.

a "math" file, holds the credential stealer and the worm that spreads it to other packages.

The worm exfiltrates npm and GitHub tokens, cloud credentials, and AI coding tool configuration files. It also establishes persistence, so attackers keep access after you remove the package. One infected install can give an attacker the keys to your pipelines and your AI agents at the same time.

 pointed out that this attack closely resembles the August compromise of the cacheable and keyv packages. Both are npm worms built on the mini Shai-Hulud code TeamPCP open-sourced this spring, and both use the same two-file pattern. There’s no evidence yet that the same group is behind both. The Hacker News reports that the attack shows attackers are now going after the AI tools developers rely on.

Two questions determine your exposure: did you install 

Compare the packages and versions in your lockfiles (

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.

Check whether preinstall scripts can execute.

 Determine your npm client version and whether lifecycle scripts are enabled in your environments. If you are on npm 12+ with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 could have run on a developer machine or CI runners, remove it. Then rotate npm tokens, cloud credentials and any secrets reachable from that environment, and review recent publish activity on your own packages.

Check Cloudsmith client and package logs.

 Review your Cloudsmith client logs and the package’s download logs to see whether 

 was requested or pulled. Client logs show which environments attempted to resolve the package. Package logs show whether the version entered your repository cache and which identities or pipelines downloaded it.

 Without a cooldown or malware policy, a developer or pipeline may have pulled 

 into your Cloudsmith cache. Search for it and quarantine any copies.

Old, dormant projects with pinned references are usually low risk, because a locked dependency tree keeps the version it already has. The exposure comes from a fresh install or a lockfile refresh that resolved to 

How Cloudsmith keeps newly published malicious packages out of your builds

Public registries supply most of your dependencies, and they serve the ecosystem well, but pulling from them straight into builds also means a malicious version can reach you minutes after it’s published. Cloudsmith sits between the public registry and your developers and pipelines as one policy-enforced control point. Two popular policies at Cloudsmith are cooldown policies and malicious package policies, which work hand in hand. Cooldowns handle the versions nobody has vetted yet. Malicious package policies take over once a version is known to be malicious.

Many package managers have client-side cooldowns built in, but they can be difficult to manage at scale for enterprises. Cloudsmith enforces the cooldown at the registry, whatever the client version or script settings, by holding back newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published, pulled into builds within minutes or hours, then withdrawn. A cooldown policy keeps those versions away from your teams during the window when they are most dangerous, giving the ecosystem time to flag them.

When the community does flag a version, malicious package policies act on it. Packages flowing through Cloudsmith are scanned for malware and matched against our database of malware advisories. With 

 from Cloudsmith, you can block versions flagged as malicious or matching known indicators. Once a package is identified as compromised, the policy stops it from reaching any consumer behind Cloudsmith, including after the cooldown window ends, and no developer has to update a manual blocklist.

When installs resolve through Cloudsmith, you get one place to enforce controls and one audit trail of what entered your environment. “Were we exposed?” becomes a search of your own records, rather than reconstructing it across every machine and pipeline. Policies only cover traffic that routes through them, so the practical first step is making sure your installs go through Cloudsmith instead of going straight to public registries.

With these controls in place, you can answer the next npm worm with one search of your Cloudsmith records.

Tensorlake SDK npm package compromised

If you were hoping for a relaxing summer break without a software supply chain attack, the latest news will disappoint. Early on July 14th 

 identified that an attacker compromised AsyncAPI repositories and used the projects’ own CI/CD pipelines to publish four malicious npm packages. Together these packages see more than 2.9 million downloads a week, with @asyncapi/specs accounting for roughly 2.7 million of them.

Here’s what we know so far, why so many conventional defenses would have let these packages through, and what a governed control layer does about it.

The attacker exploited a misconfigured GitHub Actions workflow in the asyncapi/generator repository to steal a highly privileged token belonging to the project's automation account. They used that token to push a commit that triggered the release pipeline, which published trojanized packages to npm under the trusted @asyncapi namespace. A second repository in the same organization was then used to publish the highest-impact package, @asyncapi/specs.

For a full breakdown of the attack, Wiz’s post provides an excellent 

This attack has two details that matter for what follows. First, the malicious code was hidden inside otherwise legitimate source code and it ran on package import rather than install. Second, once triggered it installed a persistent credential stealer that swept for browser passwords, SSH keys, npm and GitHub tokens, and cloud credentials.

Why security scanners may have allowed these packages through

None of the usual signals a build environment relies on would have stopped these downloads.

 The packages came from the correct namespace, published through the project’s real release pipeline using a real maintainer token.

The versions were brand new, so no intelligence existed yet: 

At the moment of publication, no advisory named these versions as malicious. A team pulling @asyncapi/specs@latest in the minutes or hours after publication would have received a clean bill of health from every feed, because the community hadn't identified the compromise yet. This is the zero-hour window, and pulling directly from a public registry means running straight into it.

Install-time scanning looked in the wrong place:

 Many defenses focus on preinstall and postinstall hooks, because that's where supply chain payloads have historically lived. This payload executed on import instead. Tooling watching only the install lifecycle would have seen nothing.

 Even a developer inspecting the source would have had to scroll past hundreds of blank spaces to find the payload.

This pattern is consistent across many of this summer’s software supply chain attacks. When packages flow directly from a public registry into a build without a control point in between, a compromise can reach your environment because nothing was positioned to intercept it.

Check your lockfiles for the compromised versions

Assume secrets are exposed on any developer machine or CI runner that installed an affected version. Rotate npm tokens, GitHub tokens, SSH keys, AWS access keys, and browser stored credentials.

Audit CI/CD secrets for any pipeline that ran npm install during the compromise window.

The steps above are helpful but reactive, taking place only after a malicious package is already inside your environment. These steps also don’t scale, relying on someone to spot the advisory, trace which builds pulled what, and rotate the right credentials before an attacker uses them.

Artifact management platforms can add a control layer ahead of package pulls to prevent some of these dangers from ever becoming present. Simply put, when detection and response move upstream and run automatically, compromised packages are stopped or contained upstream.

Cloudsmith is that governed control layer. Every package that enters a Cloudsmith workspace, whether proxied from a public registry or published internally, is evaluated against policies that assess risk, and permitted or blocked before it reaches a developer machine or CI pipeline. Two capabilities map directly to how the AsyncAPI attack played out.

With Cloudsmith as a private registry proxying npm, PyPI, Maven Central, and others, npm install routes through Cloudsmith rather than straight to the public registry. Every package, including transitive dependencies, flows through one control point you can see and govern. Without that layer, there's no place to intercept a poisoned @asyncapi/specs on its way into a build.

 to help businesses vet new packages for risk: they set a minimum age a package must reach before it can be used. That closes the window most of these attacks target, the gap between a malicious package going live and an advisory going out, Cloudsmith’s cooldown policies are enforced at the index level. Versions younger than the age you set are filtered out before the package manager ever sees them, with builds resolving cleanly to the next available version.

Cooldown with Cloudsmith this summer. Relax knowing that Cloudsmith checks every open source dependency your team pulls, keeping malware like this out of your artifacts. 

 today about defending against malicious package attacks.




Inside the AsyncAPI npm supply chain attack

Software Bills of Materials (SBOMs) are critical for transparency and compliance. Think of them as the ingredients list for software, a simple record of what went in. But as attackers continue to target and exploit software supply chains, that ingredient list plays an increasingly important role in securing your software supply chain.

When you index SBOMs they become an accessible part of day-to-day workflows. They give you a clearer view of what you’re actually shipping and provide enough detail to make decisions earlier, before a risky dependency makes its way further downstream.

This post focuses on the shift in SBOM usage from descriptive document to proactive security tool. We’ll look at how SBOMs support prevention and how teams use SBOM-based policy enforcement to keep risks out of their pipelines.

A container image may look straightforward on the surface, but the real risk often sits several layers deep. The build process can indirectly introduce transitive dependencies and SBOMs expose that level of detail.

Once you have a detailed account of what’s inside an image, you can enforce rules that reflect how you want to build and consume software.

When using SBOMs for prevention, teams can:

Block containers that include components with known vulnerabilities

Apply license policies to the full contents of an image

Catch issues buried multiple levels down the dependency tree

Make security checks consistent across teams and pipelines

Put simply, SBOMs add context to policy decisions by exposing the components inside an image. Alongside metadata, SBOMs make it possible to apply existing rules more precisely when transitive dependencies introduce risk.

How Cloudsmith supports SBOM-driven prevention 

To make SBOM-based policy enforcement dependable, teams need two things: 

Current intelligence about vulnerabilities and malicious packages

A consistent control point that evaluates every container in the same way

Cloudsmith provides both through continuous scanning and automated policy enforcement.

Cloudsmith automatically generates CycloneDX format SBOMs during container image package synchronization. Once created, SBOM data is accessible by the 

 (EPM) schema, allowing you to incorporate them into security policies. You can also retrieve SBOMs via API or download them directly from the Cloudsmith UI.

For non-Docker artifacts, you can store SBOMs directly within packages. More information about how Cloudsmith generates and handles SBOMs is available 

EPM evaluates artifacts automatically whenever they’re pushed, synchronized, or re-checked due to updated intelligence. Built on Open Policy Agent (

) to be highly flexible, EPM enforces policies on both artifact metadata and Cloudsmith-generated SBOM contents, then applies the outcome you define: allow, flag, quarantine, or block.

High-risk or vulnerable component versions

Threat intelligence changes constantly. Risks can emerge through newly published CVEs, the identification of malicious packages, or upstream dependency changes. Cloudsmith keeps this information current by ingesting data from sources like Aqua Trivy, OSV, NVD, the GitHub Advisory Database, and the OpenSSF Malicious Packages project. 

 scoring adds context around how likely a vulnerability is to be exploited in practice.

Cloudsmith’s Continuous Security feature checks these data sources for new vulnerabilities every hour and matches them to artifacts in your Cloudsmith repositories. When Continuous Security detects a threat that affects an artifact in your workspace it triggers an Enterprise Policy Manager policy evaluation with the vulnerability data included in the policy input. This removes the gap between the existence of new information and your system’s ability to act on it.

Because EPM understands SBOMs, Cloudsmith can enforce policies at the component level, not just at the image level. This gives teams fine-grained control without adding friction to developer workflows.

Because of the nature of software supply chain threats and vulnerabilities, developers and security teams need policies that meet threats as they arise. Both proactive and reactive policies play a role in your overall security posture.

These policies help restrict known issues and non-compliant components before they land in a pipeline.

License enforcement: Check transitive dependencies for licenses that don’t meet your organization’s requirements.

Vulnerability thresholds: Define a policy that quarantines any image containing a component with a CVSS score above a specified level.

The pace with which threats emerge makes it impossible to rely solely on proactive policies. Reactive rules can function as an important zero-day stopgap. These rules give teams a predictable way to lock down newly identified risks, before they hit OSV and other data sources, without chasing them manually.

Deny rules for specific components: A deny rule for a specific package or version applies both to direct package downloads and to any Docker image that includes that package as a component, ensuring the same restriction is enforced regardless of how the package is consumed.

Turning SBOM visibility into policy enforcement at scale

SBOMs give you insight into the components you’re shipping, but their true value is in the action(s) this insight triggers. Enterprise Policy Manager lets you use that insight to trigger actions that keep known risks out of your pipeline. EPM uses SBOMs to ensure every component in your pipeline meets your organization’s specific security and license requirements, automatically and at scale.

: Put your SBOMs to work. Contact Customer Success to enable Enterprise Policy Manager. 

: See why the world's leading enterprises trust us to automate artifact policy. 

Q: How does SBOM enforcement differ from traditional vulnerability scanning?

Traditional scanning often focuses on the final artifact's metadata. SBOM enforcement looks at the "ingredients" list (the dependencies) of the artifact, allowing you to block specific internal components even if the top-level artifact is marked as safe.

Q: Can Cloudsmith EPM block builds based on OPA policies?

Yes. Cloudsmith EPM uses Open Policy Agent (OPA) to evaluate artifacts at the moment they are pushed. If an artifact violates a Rego policy (e.g., contains a banned license), EPM can quarantine the file immediately and prevent it from being downloaded, keeping non-compliant packages and dependencies out of your builds.

Cloudsmith Blog

Critical PHP vulnerabilities in PHP2Shell expose web infrastructure to remote code execution

LiteLLM 1.107.0 compromised on PyPI

Tensorlake SDK npm package compromised

Inside the AsyncAPI npm supply chain attack

From ingredient list to control point: SBOM-based component-level security