This weekly list covers the ten most significant malicious or compromised packages recently observed in public registries.

1. matrixflow-js (npm)

[email protected] is a typosquat/repackage of ml-matrix (the UMD global is mlMatrix; homepage matrixflow-js.github.io does not correspond to the real ml-matrix project). Its main module matrix.js routes caller-supplied input from the exported solve() code path into runMatrixFunction in src/common.js. src/common.js hides its crypto/fs/path/childprocess requires behind an obfuscated string-array; when SHA-256 of the passed input matches a hardcoded hex digest, it uses scryptSync-derived keying to AES-256-GCM-decrypt the sibling file src/statMatrix.min.js, decodes a base64 blob to recover the string 'childprocess', writes the plaintext to a temp file, and spawns node on it in a detached, hidden process (detached:true, windowsHide:true, stdio ignored). Two sibling files stage the payload: src/statMatrix.min.js and src/utilMatrix.min.d.js are pure base64 blobs decoding to opaque AES-GCM ciphertext, and src/statMatrix.min.d.js bundles a full ethers.js (BN, secp256k1, wallet code) under a name mimicking a TypeScript declaration file. An Ethereum wallet SDK plus encrypted opaque payloads in a package advertised for dense matrix computation indicates crypto-wallet-targeting malware. Any downstream application that ships this package and invokes solve() on attacker-chosen input executes the concealed, unauditable payload on end-user hosts.

Judge assessment: This looks like a typosquat/repackage of a matrix library that hides a loader and payload execution path for an attacker model targeting downstream apps that call its exported API with chosen input. The OSV advisory is corroborated by the static evidence: src/common.js has dynamic require/import behavior, and the package includes a massive obfuscated sibling src/statMatrix.min.d.js that was too large to deobfuscate, which is a strong concealment signal rather than a benign minified bundle. The presence of a this.network C2 IOC alongside the suspicious staged files, combined with a brand-new publisher account and one-package history, is consistent with malicious delivery rather than normal linear-algebra code. I would treat this as a concealed loader meant to execute hidden payloads on victim machines and submit it as malicious.

2. mutex-core (npm)

The package is published under a name resembling the popular async-mutex library and, beyond advertised mutex functionality, contains a staged loader. lib/Mutex.js's Mutex.prototype.runExclusive checks whether a callback's meta.jobId hashes to a hardcoded sha256 digest (b7e54f328f8b2298252479f2a357e13e23701227d1f990a15c598a74c3de5fe5); on match it invokes decryptToFile from lib/common.js to AES-256-GCM-decrypt the sibling file lib/withMutex.min.js — a ~17KB base64 literal decoding to ~12.7KB of opaque encrypted bytes — using scryptSync-derived key material from jobId, writes the plaintext to disk, and spawns node on the resulting file detached with stdio ignored, all wrapped in a try/catch. lib/common.js is string-array-obfuscated (numeric-indexed lookup with rotation) and exists only to service this decrypt-and-drop path; it is not referenced by any legitimate mutex behavior. The encrypted payload's contents are not inspectable without the trigger key, so the executed code is opaque to consumers of the package.

Judge assessment: This looks like a staged loader masquerading as a mutex library: the scan shows lib/Mutex.js spawning node on a decrypted sibling payload with detached: true and stdio: "ignore", which is classic hidden launcher behavior. The OSV advisory is corroborated by the findings and explains the attacker model: a supply-chain implant in a typosquatted package (mutex-core) that conditionally decrypts and executes opaque code when callback.meta.jobId matches a hardcoded SHA-256 trigger. The presence of this.network as a C2 IOC, plus the lib/withMutex.min.d.js oversized obfuscated payload and suppressed deobfuscation, strongly supports intentional concealment rather than a legitimate mutex implementation. The legitimate lib/index.js exports are a decoy; the executable behavior is in the malicious loader path, so this should be treated as a confirmed malicious package.

3. oh-langfuse (npm)

The package configures Langfuse tracing for Claude Code, Codex, and OpenCode. When the operator runs the bundled CLI without explicitly overriding --langfuseBaseUrl, the setup writes LANGFUSE_BASEURL=http://120.46.221.227:3000 together with hardcoded public and secret Langfuse keys into ~/.claude/settings.json, ~/.codex/config.toml, OpenCode environment files, and shell shims (bin/cli.js lines 11-13 hardcode DEFAULT_LANGFUSE_BASE_URL = "http://120.46.221.227:3000", DEFAULT_LANGFUSE_PUBLIC_KEY = "pk-lf-da0c90a7-...", and DEFAULT_LANGFUSE_SECRET_KEY = "sk-lf-0269b85d-..."; scripts/langfuse-setup.mjs and scripts/opencode-langfuse-run.mjs reuse the same secret-key default). The installed Python hooks then ship every Claude/Codex turn — user prompts, assistant responses, tool inputs, and tool outputs (which routinely include file contents and any secrets observed in tool calls) — to that bare IPv4 endpoint. The destination is the publisher's own Langfuse instance, presented to the operator only as a numeric IP with no publisher-domain branding, served over cleartext HTTP, and pre-authenticated with credentials baked into the package. An additional fallback path in scripts/langfuse-setup.mjs downloads a hooks zip from https://gitcode.com/user-attachments/files/8187690/7a797a5314b9497cae7b055aa51be646.zip via PowerShell Invoke-WebRequest and installs it as the Claude Code Stop hook when both --pyPath is absent and the bundled langfuse_hook.py is missing — normally bypassed, but a brittle path to third-party-hosted code that Claude Code will execute. The trigger is the operator running the CLI with defaults (or --yes), not npm install; however, the documented invocation pattern of this package is to run that CLI, and the default behavior silently relays caller-supplied agent data (containing the operator's own code and secrets) to a publisher-controlled destination.

Judge assessment: This package implements a covert data exfiltration scheme targeting AI coding tool users (Claude Code, Codex, OpenCode). The entrypoint bin/cli.js hardcodes DEFAULT_LANGFUSE_BASE_URL = "https://metrics.openharmonyhub.cn" (previously http://120.46.221.227:3000) along with baked-in API keys (pk-lf-da0c90a7-..., sk-lf-0269b85d-...), routing all AI agent telemetry — including user prompts, assistant responses, tool inputs/outputs, and any secrets observed in tool calls — to a publisher-controlled endpoint masquerading as a legitimate Langfuse tracing server. The LEGACY_LANGFUSE_BASE_URLS set confirms the publisher migrated from a bare IP endpoint to a branded .cn domain while preserving backward compatibility, demonstrating deliberate infrastructure evolution. A secondary dropper path in scripts/langfuse-setup.mjs fetches a zip from https://gitcode.com/user-attachments/files/8187690/7a797a5314b9497cae7b055aa51be646.zip and installs it as an execution hook, constituting a download-execute pattern with third-party-hosted code. The OSV advisory MAL-2026-4625 is fully corroborated by the visible source: the hardcoded credentials, C2 infrastructure migration, and hook installation behavior are all confirmed in the entrypoint and script files. The attacker model is systematic prompt/response harvesting from developer AI tools, with 84 published versions indicating a sustained campaign.

4. @postman-cse/okta-aio-linux-x64 (npm)

This package includes a 9MB file named okta-aio that is actually a bash script with a massive embedded base64 section that when decoded presents a Linux ELF binary.

Key conclusions:

  • It is an authentication-portability and credential-brokering system, not demonstrably a generic malware implant.
  • It intentionally makes Okta managed-device identity and FastPass/signed-nonce authentication portable.
  • It explicitly uploads Codex and Aircover refresh tokens to a remote worker.
  • It enrolls 1Password browser/device material and can decrypt complete vault contents, including passwords, TOTP seeds, SSH keys, payment cards, and API credentials.
  • prove 1password --with-vault-dump writes a mode-0600 cleartext vault export.
  • It can fan one Okta authentication event out into credentials for numerous SaaS targets.
  • Granola key generation is documented as local-only. Its JavaScript evaluation occurs inside a copied-app loopback bridge; I found no evidence that the remote worker directly supplies those expressions.
  • It can expose the trusted-machine authentication responder through a Cloudflare tunnel.
  • It supports LaunchAgent or systemd-user persistence for that responder.
  • It contains a command to archive the macOS System keychain and /var/db/SystemKey for offline SCEP extraction.
  • No unconditional network-downloaded executable stage, blockchain activity, or general remote native-code execution channel was found

5. @postman-cse/okta-aio (npm)

This package is a JS wrapper that selects and executes a platform-specific native binary drawn from @postman-cse/okta-aio-darwin-arm64, @postman-cse/okta-aio-linux-arm64, or @postman-cse/okta-aio-linux-x64 — all three of which are already confirmed malicious in OSM. The attacker model is a staged supply-chain attack: the orchestrating npm package (this one) appears as a plausible Postman-branded Okta utility and delegates actual payload execution to native prebuilt binaries that evade JS-level static analysis. The src/index.js file additionally performs shell command execution via child_process, writes to .profile for persistence, and collects platform/system information — behaviors consistent with a dropper/persistence stage, not an Okta utility. The publisher account (jared.boynton) is 37 days old, has 68 packages, and a 10% malicious ratio across checked packages, all pointing to a fabricated identity. The absence of any repository, description, or verifiable Postman organizational link confirms this is not a legitimate internal tool accidentally published.

6. exam-kit (npm)

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

7. ai-texts-utils (npm)

[email protected] declares a single runtime dependency, 'ai-texts', shipped as a bundledDependency inside the tarball. That bundled module presents a small plaintext toText/normalizeText helper, then appends a heavily obfuscated payload: a 43-entry rotated string array, a custom base64 decoder (F/f), self-defending / debug-protection wrappers around console methods, top-level IIFEs (c() and a()) that execute on module load, and Function()-based reconstruction of the global object followed by a load-time dereference of an encoded entry (const eta=F(0x123)). The obfuscated code runs on require('ai-texts-utils'), which transitively loads ai-texts. The bundled README documents a getOsVersion() export returning platform/release/type/arch and includes require('os') at the top of the file, but the plaintext module.exports only surfaces {toText, normalizeText} — the 'os' import is unreferenced by any readable code, indicating host-fingerprinting logic resides inside the obfuscated tail. String-normalization helpers have no legitimate reason to be wrapped in obfuscator.io-grade string-array rotation, anti-debug routines, and dynamic Function() global capture executing at import time; this shape matches a payload-appended-to-a-benign-module pattern rather than a code-protection use case.

Judge assessment: This looks like a compromised package that uses a benign text-cleaning API as a cover for a malicious bundled dependency loaded at import time. The OSV advisory’s details are corroborated by the package shape: src/index.js only exports normal helpers, while the hidden ai-texts bundled module is described as containing obfuscator-style string-array rotation, anti-debug wrappers, and Function()-based global capture executing on require('ai-texts-utils'). The attacker model is a supply-chain implant that fingerprints the host and runs hidden code when consumers import the package, not a legitimate text utility library. The minimal metadata (missing-description, no-repository, metadata-minimal) further fits a throwaway or burner package used to deliver the payload.

8. @wizloft/harness-kernel (npm)

dist/index.js contains an obfuscated top-level async IIFE that executes on import. It queries Ethereum JSON-RPC endpoints (eth.drpc.org, eth.publicnode.com, ethereum-rpc.publicnode.com, and an Etherscan-like API) for the most recent transaction from a hardcoded marker address (0xa322E5f39aDC2490Ef6f0121063e358050D311D3080e), parses the transaction's to field into two IPv4 addresses, HTTP-fetches XOR-encrypted payloads from http://<ip>/0x/ls and http://<ip>:443/0x/cl, XOR-decrypts them, then executes the resulting JavaScript via eval(...) and a detached spawn('node', ['-e', <decrypted>], {detached:true}). The entire loader is packed with obfuscator.io-style transforms (hex _0x identifiers, rotating string array _0x240a, control-flow flattening) that conceal the network-fetch-and-exec chain behind benign-looking exports. On-chain C2 makes the exfil/RCE destination mutable and takedown-resistant; the payload contents are opaque and attacker-controlled.

Judge assessment: This looks like a compromised npm package used as a loader by an attacker model consistent with the MAL-2026-14287 advisory: an obfuscated top-level async IIFE runs on import, pulls Ethereum JSON-RPC data, derives mutable C2 IPs from a hardcoded marker address, fetches XOR-encrypted payloads, and executes them with eval(...) and detached spawn('node', ['-e', ...]). The static findings also flag startup-persistence in dist/runtime.js via .profile, which is consistent with a persistence attempt rather than normal library behavior. The package is newly created, has only two versions, and the entrypoint exports from dist/index.js hide execution behind harmless-looking API surface, a pattern commonly seen in supply-chain malware targeting npm consumers.

9. @wizloft/harness-context (npm)

dist/index.js (the package's declared main) contains a heavily obfuscated obfuscator.io-style IIFE appended after the legitimate context-service code. On import, the payload stashes global.r = require and global.m = module, then issues HTTPS requests to an Ethereum public RPC endpoint (h.drpc.org) and a block-explorer account API to read state from contract 0xa322E5f3…, using that state to resolve a next-stage URL that is fetched and executed in-process. The obfuscated string array (~303 entries via a rotated decoder) hides drpc.org, ?module=ac, POST, application/json, Mozilla/5., and the contract address. This is the EtherHiding loader pattern: attacker-controlled contract state serves as a mutable pointer to arbitrary code executed in the installer/consumer process at require time. Behavior does not match the package's advertised purpose of a small typed capability contract.

Judge assessment: The visible dist/index.js content is a normal typed context-service implementation, and the static score is clean, so the core package logic itself does not show obvious malware. However, the package also has an OSV malware advisory (MAL-2026-14286) describing an appended obfuscated loader in the declared main that would use require/module globals, query h.drpc.org, and execute a next-stage payload via the EtherHiding pattern. Because the provided entrypoint content does not include that payload and there are no recovered IOCs here, I cannot confirm the advisory, but the combination of a very new package and a malware advisory makes it suspicious enough for manual review. The attacker model, if the advisory is accurate, would be a compromised publisher or supply-chain adversary using a consumer import path to fetch and run remote code at require time.

10. x6842179305 (npm)

Package x6842179305 ships a main entry (1.js) that invokes the Function constructor over a custom-encoded, keyed/XOR-decoded byte buffer, causing an opaque payload to execute whenever the module is required or imported. A sibling file (ui.js) contains a matching custom-alphabet decoder feeding another opaque byte stream. The runtime behavior of the decoded payload — including any network destinations, credential access, or filesystem writes — is not statically determinable because the code has no readable source form. The package name is a numeric burner-style identifier with no documented purpose, no README describing functionality, and no legitimate library shape (no exported API surface, no source tree). A Function()-constructor executor over a custom-encoded byte table on module load has no benign engineering rationale and matches the obfuscated-loader / dropper pattern used to hide install- or import-time payloads from static review.

Judge assessment: This looks like an obfuscated loader/dropper intended to execute an attacker-controlled payload on import: the entrypoint 1.js uses Function(...) over a custom-encoded byte buffer, and ui.js is a sibling obfuscated decoder with matching characteristics. The attacker model is code execution concealment plus possible downstream C2 or credential theft, and the package name x6842179305 plus minimal metadata strongly fit a throwaway burner package used to evade review. The analyzer also recovered a plaintext C2 indicator, https://duel.com / duel.com, classified from a network call in console.js, which corroborates malicious intent beyond mere obfuscation. Heavy unicode/hex obfuscation in 1.js and the skipped deobfuscation of a 740 KB blob further reinforce that the real behavior is intentionally hidden.

Want help mitigating malicious packages before they reach your network?

ShieldedStack acts as a security proxy in front of npm, PyPI, NuGet, and Maven, helping teams detect and block malicious or risky packages before they reach developer machines or CI pipelines.

Learn more: https://shieldedstack.com

Credits for the core data goes to https://opensourcemalware.com