By NHI Mgmt Group Editorial TeamBased on OXSecurity: “Malware-Slop 2: Malicious npm Package Leaks Its Own Bot’s Telegram Private Token” (June 4, 2026)

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 says a malicious npm package exfiltrates host data to Telegram, downloads a second-stage payload, and leaks the threat actor’s own bot token.

Why it matters: IAM, PAM, and NHI teams should treat package compromise as both malware delivery and secret exposure risk, because attacker-controlled tooling can harvest developer machine data and credentials at the same time.

Context

Malicious packages now serve as both delivery mechanism and telemetry channel, which makes software supply chain hygiene a governance problem as much as a detection problem. In this case, the package behaved like an infostealer and downloader while also exposing the attacker’s own Telegram bot token. That combination matters because developers’ machines often hold tokens, credentials, and build access that can widen the blast radius quickly.

The identity angle is real here: the malware is not just code on a host, it is code that reaches into developer environments where human credentials, service tokens, and automation secrets often coexist. When those environments are not tightly segmented, a package install can become a credential exposure event as well as an endpoint compromise. That is typical of modern supply-chain malware, not an edge case.

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 does secret leakage from attacker tooling matter to defenders?

A: Because exposed operator tokens can reveal the attacker’s infrastructure, telemetry channel, and sometimes the broader campaign relationship. That turns the malware into a source of intelligence as well as a source of compromise. Defenders should treat leaked bot or API tokens as evidence to revoke, monitor, and correlate with other infection indicators.

Q: What are the signs that a package install is being used as a loader rather than a simple library update?

A: Look for hidden script generation, background execution, remote payload retrieval, and unexpected outbound connections from developer endpoints. Those behaviours indicate the package is staging further code rather than delivering a single self-contained function. When they appear together, the install path should be treated as an active intrusion path, not routine dependency activity.

Q: How should teams respond when package-based malware can touch developer and CI secrets?

A: Contain the affected environment first, then revoke the tokens and publishing credentials that were reachable from it. After that, rebuild the systems that executed the malware and inspect repositories for unauthorised changes. The key point is that response must address both code integrity and NHI compromise, not one or the other.

Technical breakdown

How malicious npm loaders stage exfiltration and second payloads

This package behaves like a loader, which means its first job is to establish a foothold, collect basic host telemetry, and then fetch additional code. Loader-style malware is attractive because the initial package can stay small and look benign while the real behaviour arrives later from a remote source. In this case, the package sends data to an attacker-controlled Telegram channel and attempts to pull a second-stage JavaScript payload from a raw IP address. That pattern makes static review harder and creates a separation between initial distribution and later execution.

Practical implication: Treat package execution as a multi-stage event and block unknown outbound retrieval paths from developer workstations.

Why Telegram Bot API use creates a dual risk for defenders

Telegram Bot API traffic is useful to attackers because it offers a simple exfiltration path and an easy way to monitor infections. The same channel can carry victim telemetry, operator notifications, and operational errors, which means the attacker’s own tooling may leak intelligence. Here, the bot token itself was exposed inside the malware, turning a reporting channel into an attribution source. For defenders, that matters because malicious infrastructure often reveals more than it hides when operators reuse cheap, low-friction services for command and control.

Practical implication: Inspect outbound bot-API traffic as both exfiltration and intelligence opportunity, then revoke exposed tokens immediately.

Why developer endpoints need secret-aware runtime controls

Developer machines are high-value targets because they often hold access tokens, package manager credentials, cloud session material, and build-system permissions. A malicious npm package can therefore become a bridge from ordinary software installation into secret exposure and later compromise. The presence of hidden PowerShell execution and execution-policy bypass also shows how attackers try to reduce user visibility while staying inside a trusted workstation context. That is a governance failure when endpoint controls, secret discovery, and lifecycle management are treated as separate problems instead of one control plane.

Practical implication: Combine secret discovery, endpoint execution controls, and rapid credential revocation for developer environments.

Threat narrative

Attacker objective: The attacker’s objective is to steal host data and secrets from developer environments while maintaining a lightweight distribution channel for second-stage execution and infection monitoring.

  1. Entry occurs when a developer installs the malicious npm package cms-store-ren into a workstation or build environment.
  2. Credential and telemetry harvesting begin as the package collects host information and sends it to an attacker-controlled Telegram channel while also exposing the operator’s own bot token.
  3. Escalation continues when the package generates a hidden PowerShell script and attempts to download and execute a remote JavaScript payload from an IP address.
  4. Impact is the potential theft of developer credentials, infected endpoints, and attacker-facing intelligence that can be used for broader follow-on compromise.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Malicious package abuse is now a secrets governance problem, not just a malware problem. The package here is not valuable only because it is malicious code; it is valuable to the attacker because it runs where developer secrets already live. That means package trust, runtime telemetry, and secret inventory all sit in the same risk path. Practitioners should stop treating dependency hygiene and credential governance as separate workstreams.

Self-leaking attacker infrastructure is a detection clue, not a curiosity. The exposed Telegram bot token shows how low-discipline operators can reveal their own command channel while trying to collect victim data. That creates a practical advantage for defenders, but only if malware review, threat intelligence, and token revocation are connected quickly. The named concept here is attacker-side secret leakage: adversary tooling that exposes its own credentials while stealing yours, which can accelerate attribution and containment.

Developer workstations are privileged identity zones. In many programmes, they are still treated as ordinary endpoints even though they hold package credentials, cloud tokens, and build access. That mismatch is why a single malicious install can become a broader identity exposure event. The correct governance model is to treat developer endpoints as high-trust identity concentration points and apply tighter runtime controls accordingly.

Hidden execution and remote payload retrieval show why static package review is insufficient. A malicious package can look small at publish time and still stage more dangerous behaviour after installation. Hidden PowerShell and execution-policy bypass make local inspection less reliable, while raw-IP retrieval makes infrastructure reputation weaker as a signal. The practical conclusion is that package scanning must be paired with egress control and execution monitoring.

Supply-chain malware increasingly depends on operator sloppiness as much as code quality. This case aligns with a broader pattern in which attackers upload crude tooling that still succeeds because environments accept it by default. That is an ecosystem control failure, not just an individual package failure. Teams should therefore assess how much trust their development stack places in newly published dependencies and whether that trust is still justified.

From our research library:

What this signals

Package trust now reaches into identity governance. When a malicious dependency runs where developers authenticate to package registries, cloud consoles, and CI/CD systems, the issue is no longer just code hygiene. It becomes a question of how much privileged identity material is allowed to coexist on endpoints that routinely execute third-party code.

Secret sprawl and software supply chain risk are converging. The same environment that pulls dependencies also tends to store credentials, tokens, and session material. That makes secret discovery, endpoint monitoring, and package approval policy part of one control story rather than three separate ones.

Attackers do not need sophisticated malware when the environment already trusts newly published packages and unsanitised developer workstations. The practical signal for teams is clear: reduce standing trust in build and development contexts before a malicious package turns routine installation into credential exposure.

For practitioners

  • Harden package installation controls Restrict npm installs to approved registries and enforce allow-listing for packages used in build and developer environments.
  • Revoke exposed developer secrets Assume any credentials present on machines that executed the package may have been collected, then rotate tokens, API keys, and session material immediately.
  • Block outbound bot-channel telemetry Detect and control developer workstation traffic to messaging and bot APIs, especially Telegram Bot API destinations used for exfiltration.
  • Inspect for staged script execution Hunt for hidden PowerShell execution, execution-policy bypass, and temporary-file script generation on developer endpoints that handled the package.
  • Separate developer trust domains Segment build hosts and developer workstations from general-purpose endpoints so package execution does not reach the same credential set as production access.

Key takeaways

  • A malicious npm package can act as both a loader and an infostealer, which means package trust decisions now affect endpoint security and secret exposure at the same time.
  • The article shows an attacker leaking their own Telegram bot token while collecting victim telemetry, which gives defenders an intelligence opportunity as well as a compromise indicator.
  • Developer environments need tighter controls on package installation, outbound telemetry, and credential lifecycle because a single malicious dependency can reach both code paths and identity material.

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 CIS Controls v8 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageThe package leaks attacker and victim secrets through malware behaviour and exposed tooling.
NHI-04 — Insecure AuthenticationThe malware abuses token-based channels and exposed bot credentials as part of its workflow.
NHI-07 — Long-Lived SecretsDeveloper machines and package workflows often retain secrets long enough for malware to harvest them.
Recommendation — Scan developer environments for leaked secrets and revoke any exposed tokens immediately. Harden token-based authentication paths and rotate credentials when malware exposure is suspected. Shorten secret lifetimes in development and build contexts to reduce malware exposure windows.
MITRE ATT&CKTA0006;TA0010 — Credential Access; ExfiltrationThe package collects host data and attempts to move it off-host through attacker-controlled channels.
Recommendation — Map the behaviour to credential access and exfiltration tactics when tuning detections for package-based malware.
CIS Controls v8CIS-5 — Account ManagementDeveloper and build credentials must be managed tightly once package execution is compromised.
Recommendation — Apply account management discipline to revoke and reissue credentials after suspicious package execution.

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.
  • Project API Token: A project API token is a credential used to authenticate access to a specific project or its automation context. In CI platforms, these tokens can enable integration and workflow access, but if compromised they may allow unauthorized interaction with project data or related build operations.
  • Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
  • Second-Stage Payload: A second-stage payload is the later malicious component delivered after an initial foothold is established. The first stage usually acts as a loader or stager, while the second stage contains the main functionality, such as persistence, command execution, data theft, or remote control.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to reduce exposure across build and runtime environments. It helps IAM, PAM, and security teams align identity controls with the wider security programme they support.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org