By submitting this form, you agree to our 

The npm ecosystem was hit yesterday by a malware attack affecting popular packages like 

. Both packages are typically bundled into frontend builds. Once included, the malicious payload executes.

These attacks are becoming more frequent - we reported on a 

similar attack on npm packages just 12 days ago

How you react depends on what is known about the threat:

The issue is real, but not yet reported in public databases

You cannot automatically detect or block it - your only option is rapid manual actions

The issue is documented and tracked (i.e. it has a CVE or MAL ID)

Security feeds and tools, including Cloudsmith’s Enterprise Policy Management (EPM), can use that tracking to automatically quarantine or block affected packages

, it was considered a zero-day threat (potentially compromised packages were identified, but no official designation yet).

Within 24 hours, these packages were confirmed as malicious, and added to the 

. Cloudsmith and other similar platforms can then OSV.dev updates and thereby enable automated remediations.

We recommend the following actions for all Cloudsmith customers, regardless of whether you’ve confirmed that any affected packages have been used in builds or are currently present in any of your Cloudsmith repositories.

For Zero-day threats - Block with Deny Rules

1. Add [Deny Rules] that block downloads immediately. 

This stops any installs in dev, CI, or production environments.

For this scenario, a simple set of rules targeting the compromised packages/versions would have blocked all download attempts. This protects developers who may not have heard the news yet.

See the end of this article for a full list of Deny Rules.

 to identify who pulled compromised packages and when. Cloudsmith logs are near real-time, so searching for and identifying users andservice accounts that have accessed these packages will help determine potential impact.

For N-Day threats - Quarantine and Flag with EPM

. Put policies in place to quarantine malicious packages that do not have a fix, or have not been verified and granted an exception from your security team.

Our OSV.dev feed refreshes every hour and will detect newly identified malicious packages automatically. This protects you if compromised packages are already in Cloudsmith repositories. In order to enable continuous securityadd an 

 to automatically tag and quarantine new malware.

The gap between zero-day and n-day is when development teams are most exposed. This “lag” introduces risk, against which the fastest defense is Deny Rules.

Once advisories are live and the zero-day is now an n-day, EPM and Continuous Security take over, eliminating manual effort and keeping build pipelines safe.

Looking ahead: smarter protection is coming

Cloudsmith includes detection and protection against malware and vulnerabilities as a native capability in our Ultra and Enterprise tiers. Every artifact in a Cloudsmith repository is, by definition, in a controlled, policy-enforced environment.

We’re working to include more threat intel sources, richer context, and community feeds like deps.dev, along with the ability to bring your own internal threat data into Continuous Security.

Create a Deny Rule for each separate query string.

Nick Peacock

Senior Director, Customer Success

npm ecosystem alert: What you need to do today with Cloudsmith

I learned to code in BASIC on a Commodore 64 in the early 1980s. BASIC was actually a pretty neat high-level abstraction of assembly language, which itself was an abstraction sitting on top of machine code! Since then, I’ve seen a steady stream of higher-level abstractions - relational databases, object-oriented languages, package dependencies, open source libraries, cloud-native development, containers, serverless - that have made software developers more productive, and helped us build ever more powerful applications with them.

AI is the latest abstraction layer that sits on top of existing technology, making the underlying components more powerful and easier to use. A huge amount of R&D and startup capital in the past few years has gone towards exploiting this new abstraction.

The newest and best ideas naturally attract top talent and funding. Companies and startups building cool new AI-powered apps have their choice of tech stack. And many of them are creating their new software development tool chains around Cloudsmith, which is very satisfying to Cloudsmithers.

, who built an AI-powered platform pathologists use to diagnose cancers. They manage binary packages in Cloudsmith that they use to build for a wide variety of target environments. Or 

, who builds industrial computer vision applications that improve quality and productivity, using Cloudsmith to manage binary artifacts that go into their build pipelines. 

 provides a machine learning platform for document processing and automation, built on Cloudsmith for internal development and external distribution of containers and packages. And 

, who have built an AI-powered due diligence platform, using Cloudsmith as their single source of truth for binary artifacts.

Companies that build critical infrastructure for use by other AI companies are also gravitating to Cloudsmith. Take 

, who helps organizations use, manage, and govern AI metadata with their enterprise-grade context platform. They chose Cloudsmith to make sure their artifacts are reliably and securely distributed to enterprise developers. Or 

, who distributes their SDKs and runtimes via Cloudsmith for delivery of AI-driven perception solutions to robotics and computer vision tool companies. Then there’s 

, an open source AI search platform used to develop and run large-scale applications, combining big data, vector search, machine-learned ranking, and real-time inference to enable AI applications like retrieval-augmented generation, recommendation, and intelligent search at enterprise scale. Cloudsmith supports distribution for Vespa, streamlining delivery for their open source community as well as enterprise users.

And then it’s companies who deliver AI directly to the hands of end users. 

 calls itself “the world’s most private AI,” assisting users in real time across a wide range of personal tasks. They use Cloudsmith to build and distribute packages across the software supply chain.

Cloudsmith is best known for our enterprise-grade artifact management platform, which controls and secures the software supply chain for the world’s most demanding Fortune 500 and Global 2000 organizations. But there’s a reason we also show up so often as the platform of choice for innovative AI startups and spinoffs. These companies are typically run by lean teams of seasoned software engineers. They know what they need, and they want to do it right the first time. They want developer-friendly, well-documented tools that just work.

 to manage their Hugging Face models and datasets, and we’re increasingly powering our own development of new features with AI tools. But it’s also notable that the world’s most interesting AI companies are also choosing Cloudsmith - not just to manage ML models, but to power their entire software supply chain. That’s a vote of confidence that makes us proud to be Cloudsmithers.

Glenn Weinstein

The platform of choice for AI companies

In the world of artifact management, a repository structure refers to how software artifacts—such as Docker images, Python packages, npm modules, and more—are organized, stored, and accessed. It defines how repositories are named, grouped, and managed, often aligning with how software development teams build, release, and consume software binaries across an organization.

Repository structure is a fundamental foundation of secure, efficient artifact management practices. Your goal is to create the right structure that meets the needs of your developers.

Cloudsmith has an intrinsically flexible approach to repositories. We don’t force you to have a separate repository for each format type, like most other artifact management systems do. This presents you with an opportunity to define a more meaningful structure for your repositories, and this means you have many more interesting options!

We see some common patterns among Cloudsmith users that fall into the following groups:

We’ll be covering each structure in greater detail in our upcoming blogs as part of our Repository Structure Best Practices series.

Now that we’ve identified the “what” behind repository structures, we can dig into the “why” a little bit.

We address repository structure at the beginning of our onboarding process for new customers. If you get the repo structure wrong, then over time, artifact repositories can become a ‘dumping ground’ for all manner of software artifacts. When platform engineering teams are migrating to Cloudsmith, we find that there’s often a newfound interest in organization and consolidation of software artifacts, in order to ‘do better next time’ than they were able to with their legacy solution.

Perhaps the number one question we get at this point is, “How do we balance software supply chain security best practices with a great developer experience?”

While there isn’t really one simple answer to this question, the good news is that the flexibility Cloudsmith offers in choosing the repository structure can help you to check both boxes – security AND productivity.

Key benefits of the right repository structure

Choosing a clear, intuitive structure removes significant friction for developers. If they are able to easily locate the packages they need, pull the open-source dependencies for their builds in a central location, and integrate quickly with CI/CD pipelines, you’re winning as a platform team already.

Many enterprise customers of Cloudsmith leverage a dedicated repository for all ingress packages, where open-source dependencies are proxied and cached for developers and pipelines to begin accessing. This centralized repository makes it easy for developers to remember the direct path URL for pulling on their local machines and even easier for updating their CI/CD pipelines.

With our API and UI, a developer can quickly review what packages are within a specific repository. No digging through countless folders and subfolders to find what you’re looking for!

You’ll want your developers to be able to pull dependencies, create repositories, and configure upstream sources easily. But you also want to ensure developers are working securely. Repository structure directly influences how platform teams will be able to configure repository access controls, set permissions, review vulnerabilities, and inspect audit trails for suspicious signals.

In Cloudsmith, platform teams can restrict repository access by designating only specific developer teams to have access to specific repositories. At the permissions level, you can set read/write/admin permissions for each repository. This allows for granular access control, self-serve ownership, multiformat flexibility, and better visibility into team-by-team usage.

Observability and auditability of packages within your artifact management environment are directly correlated to how fine-grained your repositories are structured. The more segmented you configure them (i.e., by specific team, application, or environment), the clearer an observability team is able to view when a package was pulled and by whom. On the contrary, if an organization just has “non-prod” and “prod” repositories with many different service accounts and users pulling packages, it might be more difficult to pin down a specific action or event.

The right repository structure really impacts an organization’s CI/CD pipelines. When pipelines are tightly coupled to poorly structured repositories, the result can be pipeline failures due to ambiguous package resolution, security risks from pulling artifacts from the wrong stage, and even increased build times due to inefficiencies in caching.

As your organization grows, what originally worked for your first few developers will often break at scale. Without a flexible, scalable repository structure, you will quickly become susceptible to artifact sprawl, naming collisions, and access control issues. Cloudsmith’s fully cloud-native architecture helps enterprise customers scale tremendously while also maintaining order and consistency across repositories.

Managing Artifacts Across Multiple Formats

Your organization is building all kinds of software, with software development across many different language formats, development teams, and environments to consider. It helps to have an artifact management platform that can support multi-format repositories, flexible upstream configurations to open-source registries, and easy-to-use package tagging.

Balancing Security With Developer Velocity

Tighter security controls and a lack of freedoms can oftentimes frustrate developers, while open policies may create security gaps. A well-thought-out repository structure strikes a balance by allowing autonomy with clear guardrails. This is part of the developer “golden path” that can be architected by a platform team. 

How the right repository structure delivers business value

Faster Software Delivery & Reduced Operational Overhead

When artifacts are easy to find, manage, and deploy, your development teams spend less time figuring out where their artifacts are and more time building great software. Reducing toil and time to market is critical for any business creating software.

Improved Agility for New Development Teams

A well-structured repository architecture supports growth by paving the way for new teams – which may include contractors – to spin up new environments (repos, teams, service accounts, tokens, etc.) by enabling replication across teams. A clear, concise, repeatable structure that only requires a few API calls makes it easier to scale without worrying about the underlying infrastructure to support globally distributed teams.

Reduced Risk With Better Visibility And Controls

Platform teams are tasked with enabling development teams to write software efficiently and securely. By having a well-defined repository structure that every development team can follow, platform teams can create clear access control policies, artifact retention policies, and user permissions. Having this visibility and control lowers the risk of shipping insecure or unverified software.

Cloudsmith’s approach to repository structure

 is a trusted advisor, helping customers design and implement the optimal repository structure that balances security, scalability, and developer productivity to support their software delivery goals.

Stay tuned for the next part of the blog series, where we will discuss the “hybrid” repository approach that factors in an organization’s services, teams, and environments in Cloudsmith.

Why does repository structure matter for developers?

A clear repository structure saves time for developers by making it easy to find and pull the right packages. It also helps avoid confusion in CI/CD pipelines and improves overall productivity.

How does repository structure improve CI/CD pipelines?

When repositories are well-structured, pipelines resolve dependencies faster, reduce build failures, and pull the right artifacts for each stage (dev, test, prod) — making delivery more reliable.

How does repository structure affect security?

Repository structure impacts how access controls, permissions, and audit logs are managed. A good structure ensures that only the right people or services can access sensitive packages.

How does Cloudsmith support flexible repository structures?

 and supports multi-format repositories, fine-grained access controls, upstream proxying for open-source, and automation via API — making it easy to design the structure you need.

How do I choose the right repository structure for my organization?

The right structure depends on your scale, security needs, and workflows. Many teams use a hybrid approach, combining team, environment, and service-based structures for flexibility and control.

Cristian Garcia

Senior Customer Success Manager

Why Repository Structure Matters

attackers published malicious versions of the popular 

 and several plugins to npm, abusing a post-install script (telemetry.js) that ran on Linux and macOS to sweep developer machines and CI for secrets (SSH keys, GitHub/npm tokens, API keys, crypto wallets). Uniquely, the payload also tried to 

co-opt local AI CLI tools (Claude, Gemini, q)

 to help with recon and exfiltration, one of the first documented cases of malware doing so.

 – A vulnerable GitHub Actions workflow was introduced in the Nx repo; although reverted in master on Aug 22, an outdated branch was later exploited to steal a GITHUB_TOKEN with read/write perms and ultimately the npm publish token.

 – Multiple malicious Nx releases and plugins were pushed over ~2 hours; within hours, npm removed them and 

2FA required for all packages and publishing moved to npm’s Trusted Publisher

, and the window, though brief, was enough to 

1,000+ valid GitHub tokens, dozens of valid cloud and npm credentials, and ~20,000 files

 exfiltrated; execution was seen on developer machines (often via the Nx VS Code extension) and in CI (e.g., GitHub Actions).

Cloudsmith integrates this data feed via 

, providing hourly checks against the OpenSSF database. When an already cached or a newly uploaded package is detected as malicious, Continuous Security works with 

 (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

Cloudsmith offers this capability as a part of our 

 (EPM) feature, a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain.

When a new threat is discovered that affects an artifact in your workspace, Continuous Security will flag it via EPM without the need for a full manual or scheduled re-scan.

In the Nx incident, entries for nx and related @nx/* packages appeared in the OpenSSF/OSV malicious-package feed within ~24 hours of first detection (e.g., MAL-2025-41443 for npm/nx, plus @nx/devkit, @nx/node, @nx/workspace, and others). With Cloudsmith’s hourly ingestion, these packages would have been automatically flagged and quarantined, shrinking exposure time and limiting downstream blast radius.

You can check out a deeper dive of how EPM uses OSV to detect and block malicious packages here.

: EPM enforces organization-wide rules automatically upon detection (no manual triage to start protecting builds).

: OpenSSF’s open database aggregates cross-ecosystem reports in the OSV schema, which Cloudsmith consumes directly.

Enable EPM and add a Malicious Package policy

 (OSV/OpenSSF source). This is the switch that turns detection into 

Understanding the defense in depth approach: 

A malicious package can be ingested into a build pipeline before threat intelligence sources like OpenSSF or OSV publish indicators, creating a blind spot during which the artifact remains undetected. Mitigating this exposure requires a defense-in-depth strategy: enforce ingress controls at the artifact repository level (e.g., Cloudsmith) to block known and suspicious packages, and implement downstream detection via CI scanners and endpoint monitoring to identify and remove compromised dependencies already in use. 

(This is about realistic risk staging: block new ingress at Cloudsmith; find and purge what’s already inside with endpoint/CI scans.)

: Even though npm has removed the bad Nx versions, follow the incident guidance (rotate tokens/keys, search for s1ngularity-repository* and results.b64, clean shell startup files, audit CI). Wiz and the Nx advisory provide concrete steps.

AI-assisted malware isn’t hypothetical anymore, it’s in mainstream OSS supply chains. Cloudsmith’s 

 that can turn multi-hour chaos into a contained non-event. Pair it with good credential hygiene and CI hardening—and insist on provenance/Trusted Publisher for your own releases, just as the Nx team has done post-incident.

Claire McDyre

Product Manager

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Across your organization, teams are rapidly adopting AI and machine learning. They’re pulling ML models and datasets from public sources like Hugging Face and wiring them into workflows that are now reaching production. For platform and security leaders, this creates a familiar challenge: artifacts are entering the software supply chain outside established governance and controls.

Unmanaged AI artifacts carry real risks. They can’t be traced back to their source, they don’t follow compliance processes, and they often bypass the review gates you rely on for code and containers. Left unchecked, they become blind spots and liabilities in your supply chain. Without action, AI artifacts become the weakest link in your supply chain security.

The answer is to manage ML models and datasets with the same level of control and oversight as every other artifact in your supply chain. By managing them through a unified platform—with shared repositories, consistent policy enforcement, and full observability—you ensure that ML workflows are governed by the same standards as the rest of your software supply chain.

The growing adoption of ML models and datasets introduces both opportunity and risk. On one hand, models accelerate delivery by enabling new capabilities at unprecedented speed. On the other hand, they introduce opaque dependencies, security blind spots, and compliance risks into the supply chain—areas where governance practices are still catching up.

Some risks begin earlier in the lifecycle, like poisoned training data or tampered weights during model creation, which can compromise a model before it ever reaches a registry. But the most immediate challenge for platform and security leaders is governance once these artifacts enter the supply chain. Teams often pull models directly from public sources like Hugging Face, bypassing review and scanning. Without versioning and provenance tracking, it’s nearly impossible to prove which model is in use, where it came from, or what depends on it. And without consistent policies, organizations struggle to demonstrate compliance when auditors or regulators come calling.

These risks can’t be left unmanaged. The question is how to bring ML artifacts under control.

ML models and datasets are artifacts, and like any artifact, they need to be versioned, audited, and controlled with the same enterprise-grade policies you’ve put in place for packages like code libraries and container images. As organizations deliver production applications powered by AI, the priority for platform and security leaders is clear: maintain visibility, integrity, and trust in the components that make up these builds.

Cloudsmith’s new ML Model registry support

A Single Source of Truth for ML Models in DevOps

Cloudsmith extends artifact management to ML models and datasets, promoting them to first-class artifacts in your supply chain. This means you can control, secure, and distribute models alongside your language libraries, containers, and other binaries, all governed by the same policies and observability already in place.

: Require approvals, license checks, and compliance gates before a model or dataset is deployed.

: Every artifact is versioned, hashed, and immutable, so tampering can be detected and blocked.

: Capture where a model or dataset came from, how it has changed, and what depends on it.

: Manage ML models (PyTorch, TensorFlow, ONNX, and more) alongside other binary artifacts in the same repositories.

: Proxy and cache models and datasets directly from the Hugging Face Hub, while continuing to use the Hugging Face SDK for training and deployment — ensuring developers keep their workflows while you enforce governance.

DevOps has always been about balancing efficiency, stability, and security. The rise of ML workflows doesn’t change that balance - it heightens the need for it. By incorporating ML models and datasets into Cloudsmith, you extend the same supply chain controls that protect your code and containers to the AI artifacts now driving production systems.

The result: faster innovation without unmanaged risk, and a single platform to govern every component that ships to production.

Learn more about Cloudsmith's ML Model Registry here.

Alison Sickelka

VP of Product

Extending Supply Chain Governance to AI and ML Artifacts

Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.


Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of 

 in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (

) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of 

 v.3.1.1 package that we know has a GNU Lesser General Public License (

) license that should trigger the policy:

 If you have a tagging response action attached to your policy, you could tag the package with 

This policy checks whether a package includes specific 

 descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the 

The policy will trigger on these kind of wildcard examples:


Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the 

 Python package and push it to Cloudsmith to cause the policy violation:

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "

" before being allowed to proceed in the pipeline.

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "

" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.


 architecture packages and blocks others like 

To trigger the above policy (which blocks all architectures 

), you'd want to upload or sync a Python package that is built for a 

 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business. Check out our official documentation on how to 

Nigel Douglas

Head of Developer Relations

Compliance policies in EPM

Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling 

 as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on 

An alarming post by Bruno Schaatsbergen on 

 highlights this issue. A user discovered an active container registry at 

, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

While it might seem unlikely that this is happening right now in any organisation, a simple 

 would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to 

, those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating 

 could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, 

 basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

 exists as a live container registry masquerading behind a one-letter typo of 

This reflects an escalation from typosquatting individual package names to targeting entire registries.

Cloudsmith Blog

npm ecosystem alert: What you need to do today with Cloudsmith

The platform of choice for AI companies

Why Repository Structure Matters

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Extending Supply Chain Governance to AI and ML Artifacts

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Choosing the Right Artifact Management Platform for Enterprise Scale

Managing Malicious Packages with Cloudsmith EPM

Malicious Package Detection in Cloudsmith

Cloud Native Vs. On-Premise Artifact Management - A Complete Overview