Eight malicious packages on the public npm registry have accumulated 40,767 downloads as part of a supply-chain campaign that researchers have dubbed MALFEX, an operation assessed to have been running since August 2023 and now believed to involve a single threat actor.
The findings, published by security firms CloudSEK and Checkmarx, describe 12 packages tied to the campaign, eight of them confirmed malicious. The payload is a combination of an information stealer and the Overlord remote access trojan — a pairing that turns a routine dependency install into a beachhead on developer machines and build environments.
Critically, the download figure should not be read as a headcount. The 40,767 downloads reflect ecosystem scale and the length of the exposure window, not 40,767 distinct compromised systems. But the number does illustrate something more uncomfortable: the campaign ran for roughly three years before being disclosed, with packages appearing credible enough to sit on the registry and attract organic installs. It is a reminder that npm's supply chain does not punish slow attackers. A patient operator can register plausible-sounding packages, seed them over months, and wait for developers to pull them in through normal dependency resolution.
That patience is what makes MALFEX different from the more recent conmon npm incident, even for readers who followed that story only briefly — conmon drew attention for its speed and visibility rather than its stealth. The contrast is instructive. Fast, loud incidents trigger responses; slow, quiet ones compound risk. Both follow a recognisable pattern — a package that looks legitimate, maintainer provenance that is borrowed or fabricated, and a payload that is only visible in hindsight.
What the payload can reach is where the real damage potential sits. Once executed on a compromised host, Overlord and the accompanying stealer can expose registry tokens, cloud provider credentials, CI/CD secrets, and access to internal source repositories. In organisations where npm access tokens are scoped broadly or reused across environments, a single compromised developer workstation can cascade into package-registry publishing rights, cloud infrastructure, or the build pipeline itself. For maintainers of popular open-source projects, the risk extends beyond their own machines to the downstream consumers of their packages.
The defensive guidance is not new, which is precisely why it deserves repeating. Dependency lockfiles remain one of the strongest practical defences against supply-chain intrusion: they pin exact versions and integrity hashes, so a new malicious release cannot be silently pulled in at build time. Teams that skip lockfiles — or allow automatic version resolution in CI — are effectively opting out of that protection. Verify maintainer accounts before adopting new dependencies, prefer packages with long, auditable release histories over newly created ones, audit registry tokens for unnecessary scope, and treat unexpected dependency updates as an incident rather than a routine chore.
For Hong Kong's technology sector, the campaign is worth noting as a reference point rather than a local event. MALFEX did not specifically target the city; the credential types it harvests — registry tokens, CI/CD secrets, cloud keys — are the same ones carried across any organisation where npm packages are embedded in the stack. For IT and security teams here, the useful questions are practical ones: where npm sits in your environment, what a token exposure would reach, and how quickly a dependency incident would surface. The attack surface is universal, and so is the case for the hygiene measures above.
One caveat should accompany any post-mortem: as of disclosure, the campaign is not considered contained. The packages were still being published under plausible identities for years before detection, and similar tradecraft can be replicated by operators who follow the same playbook. For maintainers and platform teams, the checklist above is a Monday-morning task, not a quarterly one — verify your dependencies, lock them down, and assume the next package will look just as convincing as the last eight.
Source: CloudSEK and Checkmarx research, as reported by The Hacker News on 7 October 2026.
npm 公開 registry 上的八個惡意套件累積下載量達 40,767 次，此為一項供應鏈攻擊行動的一部分，研究人員將其命名為 MALFEX。該行動被評估自 2023 年 8 月起持續運作，現時相信涉及單一威脅行為者。
安全公司 CloudSEK 與 Checkmarx 公布的研究發現，描述了與該行動相關的 12 個套件，其中 8 個已確認為惡意。其惡意載荷結合了資訊竊取器與 Overlord 遠端存取木馬（remote access trojan）——兩者配合之下，一次例行的依賴安裝即成為駭入開發者電腦及 build 環境的橋頭堡。
必須強調的是，下載數字不應被誤讀為受感染人數。40,767 次下載反映的是生態系統規模及漏洞暴露窗口的長度，而非 40,767 個被入侵的獨立系統。但這個數字確實揭示了更令人不安的事實：該行動在被披露前運作了約三年，期間套件在外觀上足夠可信，得以留存於 registry 並吸引正常安裝。這提醒我們，npm 的供應鏈不會懲罰慢速攻擊者。有耐心的行動者可以註冊聽起來合理的套件，用數個月時間逐漸投放，然後等待開發者透過正常的依賴解析（dependency resolution）將其引入。
正是這種耐心，使 MALFEX 有別於較近期的 conmon npm 事件——即使對那些只略為跟進該新聞的讀者而言亦然。conmon 引起注意是因為其速度與曝光度，而非其隱蔽性。這種對比頗具啟示性：快速而高調的事件會引發應對；緩慢而低調的則會不斷累積風險。兩者都遵循一個可辨識的模式——套件外觀貌似合法、維護者的來源屬借用或偽造、惡意載荷往往事後才被發現。
載荷能觸及的範圍，正是真正破壞潛力所在。一旦在被入侵的主機上執行，Overlord 及隨附的資訊竊取器可以暴露 registry token、雲端服務商憑證、CI/CD 機密，以及存取內部原始碼儲存庫（source repository）的權限。在一些 npm access token 權限範圍過寬或跨環境重複使用的機構中，一部被入侵的開發者工作站就可能連鎖引發後果：套件 registry 的發佈權限、雲端基建、甚至 build pipeline 本身。對於熱門開源項目的維護者而言，風險更不限於自身電腦，而是延伸至其套件的下游使用者。
防禦指引並非新鮮事——正因如此才更值得重申。依賴 lockfile 仍是最有效的供應鏈入侵防禦手段之一：lockfile 鍵定了準確版本及完整性雜湊值（integrity hashes），令新的惡意版本無法在 build 時被悄悄引入。跳過 lockfile 的團隊——或容許在 CI 中自動解析版本的團隊——實質上已放棄這層防護。採用新依賴前應先核實維護者帳戶；優先選用擁有長遠、可審計發佈歷史的套件，而非新建的套件；審計 registry token 是否存在不必要的權限範圍；並把非預期的依賴更新視為事件（incident）處理，而非例行公事。
就香港的科技業而言，這次行動值得作為一個參照點來留意，而非視為本地事件。MALFEX 並無特別針對本港發動；它所竊取的憑證類型——registry token、CI/CD 機密、雲端金鑰——正是任何將 npm 套件嵌入技術架構的機構所持有的同一類憑證。對本地 IT 及安全團隊而言，有用的問題往往是務實的：npm 在你的環境中佔什麼位置、token 外洩會觸及甚麼範圍，以及一次依賴事件會多快浮現。攻擊面具有普遍性，而上述衛生措施的理據同樣具有普遍性。
任何事後檢討（post-mortem）都應附帶一項警示：截至披露時，該行動並未被認為已受到控制。這些套件多年來一直以貌似合理的身分持續發佈，直至被偵測到；而採用同一套劇本的行動者亦可複製類似的手法。對於維護者及平台團隊而言，上述清單是週一早晨的工作，而非每季度一次的例行項目——核實你的依賴、將其鎖定，並假定下一個套件會和先前那八個一樣具說服力。
資料來源：CloudSEK 及 Checkmarx 研究，由 The Hacker News 於 2026 年 10 月 7 日報道。