Cybersecurity researchers have reported a long-running malicious campaign targeting the npm ecosystem, with several packages allegedly used to deliver remote access trojans and information-stealing malware. For businesses that build websites, e-commerce systems, internal tools or customer-facing applications with JavaScript, the case is another reminder that open-source package risk is not limited to large enterprises.

What happened

According to reporting based on research from CloudSEK and Checkmarx, a threat campaign dubbed MALFEX involved malicious npm packages designed to infect developer or build environments. The researchers said the activity has been ongoing since August 2023 and attributed it to what they assess is a lone threat actor.

The source report states that 12 packages were published during the campaign, with eight of them identified as malicious and downloaded a combined 40,767 times. The reported payloads include remote access trojans (RATs), which can give attackers control over infected systems, and information stealers, which are commonly used to extract credentials, tokens and other sensitive data.

As with many software supply chain incidents, the immediate risk is not only the package itself but where it runs. If a malicious dependency reaches a developer workstation, CI/CD pipeline or production build system, attackers may gain access to source code, secrets, cloud credentials or deployment environments.

Why it matters for European businesses

Many European SMEs and digital teams rely heavily on npm packages for websites, web applications, e-commerce storefronts, SaaS products and internal automation tools. This creates speed and efficiency, but it also means malicious packages can enter business systems through normal development workflows.

The business impact can extend well beyond a single compromised machine. A successful package-based attack may expose:

• developer credentials and session tokens
• API keys and cloud secrets stored in local environments or build pipelines
• source code and proprietary business logic
• customer-related data processed by compromised applications
• access to production infrastructure or deployment tooling

For companies operating in regulated sectors or handling personal data, a software supply chain compromise can also trigger broader governance and incident-response obligations. The exact legal impact depends on what systems and data were affected, but the operational disruption alone can be significant.

The incident is particularly relevant for businesses that outsource software work as well as those with in-house teams. Even if a company does not publish software itself, it may still depend on agencies, freelancers or SaaS vendors whose development pipelines use open-source JavaScript packages extensively.

Who may be affected

The most exposed organisations are those that use JavaScript and Node.js in active development, including:

• digital agencies building client websites and applications
• e-commerce businesses running custom storefronts or integrations
• SaaS companies and startups shipping web products quickly
• internal IT teams maintaining automation scripts or business tools
• companies using third-party developers without strict dependency controls

Risk is higher where teams install packages directly from public registries without review, allow broad developer permissions, or store sensitive tokens in local machines and CI/CD environments.

What companies should consider

European businesses do not need to stop using open-source packages, but they should reduce trust-by-default practices in development workflows. Practical steps may include:

• Review dependencies regularly and remove unused or unmaintained packages.
• Restrict installation practices so developers do not add new packages to production projects without review.
• Use lockfiles and controlled builds to reduce unexpected dependency changes.
• Scan software dependencies in repositories and CI/CD pipelines for known malicious or suspicious packages.
• Protect secrets by moving tokens and credentials out of local codebases and into managed secret stores.
• Limit developer and pipeline privileges so a compromised package cannot automatically access everything.
• Monitor npm usage across projects, especially older internal tools that may receive less security attention.
• Prepare an incident-response process for supply chain compromise, including credential rotation and build environment review.

For business leaders, the broader lesson is that application security now includes the external code your teams import every day. For SMEs, a lightweight dependency governance process can be far more cost-effective than dealing with stolen credentials, poisoned builds or a compromised customer-facing platform later.