TL;DR: A malicious npm package, cms-store-ren, exfiltrates host data to Telegram, downloads a second-stage payload, and leaks the attacker’s own bot API token, exposing how weakly controlled package publishing and runtime telemetry can aid both intrusion and attribution, according to OXSecurity. The broader lesson is that package scanning, secret detection, and egress control need to work together because malware can betray itself as easily as it infects systems.
At a glance
What this is: OXSecurity identified a malicious npm infostealer that exfiltrates developer-machine telemetry to Telegram while exposing the attacker’s own bot token.
Why it matters: It matters because software supply chain abuse increasingly overlaps with NHI exposure, where leaked tokens, hardcoded secrets, and untrusted package execution can turn developer tools into both infection vectors and intelligence sources.
👉 Read OXSecurity's analysis of the malicious npm package cms-store-ren and leaked Telegram token
Context
Malicious npm packages are a supply chain problem, but they are also an identity and secrets problem when payloads harvest tokens, session material, or other credentials from developer machines. In this case, the package was used to collect host data, report infections, and stage additional code execution, which makes the control question broader than package reputation alone.
For IAM and NHI practitioners, the key issue is not just whether a package is malicious but whether developer endpoints, build systems, and CI/CD environments can contain credential exposure once an untrusted dependency runs. That intersection between software supply chain abuse and secrets governance is exactly where basic package scanning stops being enough.
Key questions
Q: What breaks when malicious npm packages are allowed to run on developer endpoints?
A: They can turn install-time trust into code execution, then harvest browser-stored secrets, cloud tokens, and local credentials before defenders detect the compromise. The problem is not only malware delivery. It is that development endpoints often already hold identities and secrets that let an attacker move from package execution to account abuse quickly.
Q: Why do developer machines create extra risk for NHI and secrets governance?
A: Developer machines often hold tokens, API keys, certificates, and browser sessions that can access source control, cloud consoles, and build systems. If malware reaches that endpoint, those non-human identities can be used immediately or replayed later. That is why endpoint compromise and NHI exposure should be governed as one problem, not separate ones.
Q: How do security teams know whether package-installed malware is actually active?
A: Look for execution behaviour, not just package reputation. Indicators include hidden PowerShell, execution-policy bypass, unusual outbound connections, secondary script downloads, and alerting to attacker-controlled channels. Combine those signals with registry activity and endpoint process telemetry so you can distinguish a benign install from a package that is already staging follow-on code.
Q: Who is accountable when a malicious dependency enters a build pipeline?
A: Accountability is shared across engineering, security, and platform teams, but the control owner should be clear. Dependency intake, script execution, and publishing credentials are all governance points. In practice, the teams responsible for CI/CD, package policy, and non-human credential lifecycle must define who can approve, who can execute, and who can revoke.
Technical breakdown
How malicious npm packages turn into loader malware
A malicious npm package often begins as a seemingly ordinary dependency, but once installed or executed it can behave like a loader. In this case, the package collected host metadata, then contacted an attacker-controlled Telegram channel through the Bot API to report infection. That pattern gives the operator visibility into successful runs while keeping the payload small. The same package also attempted to fetch a second-stage JavaScript file from a remote server, which is a common way to separate initial delivery from later execution logic. This lets the actor change payloads without republishing the package.
Practical implication: treat package install paths as execution paths, not just software acquisition paths.
Why bot tokens and hardcoded secrets are operational liabilities
Hardcoded credentials in malware are often a sign of low operational discipline, but they still create real security value for defenders. The leaked Telegram bot token exposed the actor’s infrastructure and message channel, which can support detection, takedown, and attribution. More broadly, any embedded secret in code or packages can be recovered from the artifact itself, from logs, or from telemetry. That is why secrets management must assume the codebase, build pipeline, and artifact store are all potential disclosure points. A leaked token is not just a credential problem, it is an intelligence leak.
Practical implication: enforce secret scanning on source, package artifacts, and build outputs before publication.
Why hidden PowerShell and raw IP delivery increase detection difficulty
The malware used hidden PowerShell with execution policy bypass and fetched a remote payload from a raw IP address instead of a domain. Those choices reduce obvious user-facing indicators and can weaken some reputation-based controls. Hidden execution is a classic way to suppress visibility on the endpoint, while raw IP delivery avoids DNS-dependent detections and can simplify attacker infrastructure. Neither technique is novel, but together they show how commodity malware can combine basic evasion with lightweight staging. For defenders, the lesson is that detection must look at execution behaviour, not only filenames, domains, or package metadata.
Practical implication: correlate endpoint script execution, suspicious network egress, and package-install events in the same detection rule set.
Threat narrative
Attacker objective: The attacker aimed to collect developer-machine telemetry, maintain infection visibility, and create a path for second-stage payload execution while avoiding easy detection.
- Entry occurred when the malicious npm package was installed in a developer environment and executed as a dependency. The package then gathered host telemetry and reported the infection back to an attacker-controlled Telegram channel.
- Credential or operational access was reinforced because the package exposed the attacker’s own Telegram bot token, which revealed the exfiltration channel and supporting infrastructure. The malware also attempted to stage a second payload through hidden PowerShell execution.
- Impact came from data collection on the victim machine and the potential for follow-on code execution through the downloaded JavaScript payload. The same artefact that infected the target also created investigative leverage for defenders.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Malicious package distribution is now a secrets-exposure problem, not only a malware problem. The cms-store-ren case shows how package abuse can surface both victim telemetry and attacker infrastructure in one incident. That combination matters because the same workflow that lets an organisation consume code quickly can also expose credentials, bot tokens, and build-time secrets. For identity teams, the implication is that software supply chain governance and secrets governance now overlap in the same control plane.
Developer endpoints are part of the NHI attack surface. When malware runs on a machine used to access source control, CI/CD, package registries, and cloud consoles, it can capture more than local files. It can reach non-human identities through tokens, API keys, and session material that were never intended to leave the developer workstation. The failure mode is not just endpoint compromise, but uncontrolled credential transitivity across the developer toolchain. That makes endpoint telemetry, secret hygiene, and access scoping inseparable.
Hidden execution still defeats organisations that only inspect static package metadata. The use of PowerShell, execution-policy bypass, and raw-IP payload retrieval shows how simple tradecraft can outpace narrow package screening. The named concept here is credential transitivity leakage: once a malicious dependency runs, credentials can move from human workflow into machine-to-machine access paths faster than most review processes can react. Practitioners should treat runtime inspection as a governance requirement, not an optional hardening step.
Leaked attacker secrets are an opportunity for defenders, but they should not become the primary control assumption. The fact that the actor exposed its own bot token aided investigation, yet that kind of mistake is unreliable as a defence mechanism. Mature programmes should be able to detect the malware whether or not the actor is careless. The more useful takeaway is that malware authors routinely reuse the same weak operational patterns defenders already know how to hunt. The control question is coverage, not curiosity.
Application security and identity governance need a shared view of compromise pathways. If a package can exfiltrate telemetry, stage a payload, and encounter secrets in the same execution path, then the security model must account for code provenance, endpoint behaviour, and credential exposure together. That is a stronger fit for NIST CSF and OWASP NHI thinking than for isolated tool ownership. Practitioners should align security engineering, IAM, and developer platform teams around one incident model for malicious dependency execution.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- This reinforces why readers should also review Guide to the Secret Sprawl Challenge for the remediation and governance patterns that reduce exposure windows.
What this signals
Credential transitivity leakage: when malware reaches a developer endpoint, it can turn local compromise into NHI exposure across source control, build systems, and cloud access in one move. That is the governance gap this case illustrates, and it is exactly why identity teams need to correlate endpoint events with token use and package provenance instead of treating them as separate security queues.
Supply-chain malware also changes how practitioners should think about detection. A package that launches PowerShell, reaches out to remote infrastructure, and reports to Telegram is not just a software integrity issue. It is an identity and telemetry issue because the artefact may be operating inside the same trust envelope as secrets, registries, and developer sessions. The right response is integrated visibility across endpoint, IAM, and CI/CD controls.
For identity programmes, this pattern argues for stronger linkage between secrets lifecycle controls and software delivery governance. If leaked credentials are not revoked quickly, the compromise window extends well beyond the initial infection. That is why the operational metric is not whether a secret was found, but how quickly it was invalidated after exposure.
For practitioners
- Quarantine suspicious package installs immediately Block or alert on unapproved npm package execution in developer workstations and build runners, especially when the package spawns PowerShell, reaches out to Telegram, or downloads remote scripts from raw IP addresses.
- Scan every artifact for embedded secrets Run secret detection on source, lockfiles, package tarballs, and build outputs before release so hardcoded API keys, bot tokens, and other credentials are removed before they can be reused by attackers or defenders.
- Assume developer credentials may be exposed Rotate tokens and certificates that were present on machines where the malicious package ran, and validate whether those secrets were scoped narrowly enough to limit lateral access.
- Correlate endpoint and identity signals Join endpoint alerts for script execution with identity events for token use, package registry access, and unexpected egress so compromise chains are visible in one investigation path.
- Harden build and package trust boundaries Restrict who can publish, install, and promote packages into production pipelines, and require provenance checks before dependencies can be consumed by CI/CD systems.
Key takeaways
- Malicious npm packages can function as both malware loaders and secrets-exposure events, which makes supply chain abuse an identity governance issue as well as an endpoint issue.
- The presence of leaked bot tokens, hidden script execution, and remote payload staging shows how quickly a dependency can create both infection and intelligence value for defenders.
- Practitioners should combine package provenance checks, secret scanning, and rapid credential rotation so exposed identities do not remain usable long after discovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The article centres on exposed secrets and unmanaged credential risk in a software package. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0011 , Command and Control; TA0002 , Execution | The malware harvested telemetry, staged payloads, and used Telegram for attacker communications. |
| NIST CSF 2.0 | PR.AC-4 | This case exposes access scope and credential governance weaknesses across developer tooling. |
| NIST SP 800-53 Rev 5 | IA-5 | The incident directly involves exposed authentication material and rotation failure. |
| CIS Controls v8 | CIS-5 , Account Management | Stolen or leaked credentials from development machines fall squarely under account and token governance. |
Map suspicious package activity to these tactics and prioritise detections for hidden execution and exfiltration.
Key terms
- Loader Malware: Loader malware is code whose main job is to establish execution and fetch a later payload rather than deliver the full attack immediately. It often gathers basic telemetry, checks environment details, and then retrieves a second stage that can be updated independently by the attacker.
- Trust Transitivity: The risk that trust granted to one party is implicitly inherited by others through integrations, support channels, or delegated access. In practice, it means a compromise in one supplier or device class can extend into environments that were never directly breached.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Runtime Egress Monitoring: Runtime egress monitoring is the practice of watching outbound network behaviour while software is actually running, not only when it is being inspected statically. It helps identify suspicious callbacks, unexpected remote downloads, and covert reporting channels that package scans alone would miss.
What's in the full analysis
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- The malicious package behaviour chain, including host telemetry collection and Telegram exfiltration, as observed during analysis.
- The code and execution indicators that distinguish the loader from a normal dependency and help incident responders validate compromise.
- The attacker infrastructure details, including the leaked bot token, exfiltration channel, and associated account intelligence.
- The package name and affected version scope needed for blocklists, hunting, and internal software inventory checks.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners build the controls and operating model needed to manage credentials across developer, cloud, and automation environments.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org