Security researchers have identified a malicious package on the npm registry called imgdecode, which has been linked to the previously disclosed MALFEX software supply-chain attack campaign. According to the reported findings, the package was uploaded on 30 September 2026 and remained available on npm at the time of reporting. The package had also been downloaded hundreds of times, highlighting how quickly malicious code can enter developer workflows through public package registries.

For European businesses, the incident is not just a developer-security story. It is a practical reminder that software dependencies used in websites, internal tools, SaaS products and e-commerce systems can become an entry point into company environments, especially when development teams rely on public open-source ecosystems such as npm.

What happened

The reported malicious package, imgdecode, is described as part of the MALFEX campaign and allegedly hides a shellcode loader inside a Windows native addon. In practical terms, that means the package appears to include compiled code designed to run on Windows systems, rather than only readable JavaScript. That can make detection and review more difficult for teams that normally inspect scripts but not native binaries.

Based on the report, the package was uploaded by an account named malfexteste8. The article states that it remained available on npm at the time of publication and had recorded 979 downloads. The reporting links the package to a broader supply-chain attack pattern in which attackers publish or disguise malicious dependencies in widely used development ecosystems.

At this stage, the reported details indicate a malicious package discovery rather than a confirmed breach of npm itself. The risk comes from developers or automated systems installing the dependency into local environments, build systems or production pipelines.

Why it matters for European businesses

Many European SMEs, digital agencies, software teams and e-commerce operators depend on JavaScript tooling and npm packages to build websites, integrations, apps and internal automation. A compromised or malicious package can affect more than a single developer machine:

• Developer workstation compromise: If installed locally, a malicious package may execute code on a Windows machine used for software development.
• CI/CD pipeline exposure: If the dependency is pulled into automated build systems, attackers may gain a route into code-signing, deployment or secrets stored in pipelines.
• Credential theft risk: Supply-chain malware often aims to access tokens, environment variables, SSH keys or cloud credentials.
• Customer-facing impact: If affected code reaches production, websites, applications or e-commerce services may be disrupted or backdoored.
• Compliance and incident response costs: Businesses handling personal data or operating under contractual security requirements may face additional reporting, remediation and audit obligations if a compromise occurs.

This is especially relevant for organisations with outsourced development, mixed Windows environments, or rapid release cycles where dependency review is limited. Smaller companies are often exposed because they move quickly and rely heavily on third-party libraries without maintaining a formal software supply-chain security process.

Who may be affected

• Software companies and SaaS providers using npm-based development stacks.
• Digital agencies building websites, web apps and client integrations.
• E-commerce businesses running custom storefronts, plugins or Node.js-based tooling.
• Internal IT and automation teams using JavaScript packages for scripts, integrations and workflow tools.
• Windows-based development teams because the reported package used a Windows native addon.

The risk is higher for organisations that automatically install package updates, allow broad internet access from developer endpoints, or do not maintain a software bill of materials or dependency monitoring process.

What companies should consider

• Check whether imgdecode is present in source repositories, lock files, build scripts and developer machines.
• Review recent npm installs and identify whether the package, or related suspicious dependencies, entered CI/CD pipelines or internal package caches.
• Inspect Windows developer endpoints where the package may have been installed, especially for unusual processes, outbound connections or unauthorised binaries.
• Rotate exposed credentials if there is any possibility that developer tokens, API keys, cloud secrets or signing credentials were accessible on affected systems.
• Strengthen dependency controls by using package allowlists, lock files, internal mirrors or registry-proxy policies for approved libraries.
• Add software supply-chain checks such as dependency scanning, behavioural monitoring and review of native addons or post-install scripts.
• Limit developer privileges so a malicious package cannot easily access sensitive infrastructure or production systems.

For business leaders, the broader lesson is that open-source risk is now an operational risk, not only a developer concern. Companies that build digital products, run online sales channels or automate business processes should treat dependency governance as part of core cybersecurity hygiene.

As with many supply-chain incidents, the practical response is less about one package and more about process: knowing what dependencies are used, where they are installed, what systems they can access, and how quickly they can be removed if a threat is identified.