We started with a SafeDep analysis of mathmain on September 17, 2026. The package looked like a copy of mathjs with a different name and obfuscated code. One added call in the solver led us to the loader.

A solver calls a type check

Near the end of lusolve(), we found an extra call in the CommonJS build. The solver had already calculated its result. It then passed data from the lower triangular matrix to removeSolveValidation():

Here, l holds the lower triangular matrix and x holds the result. The solver returns x unchanged. It assigns the extra call’s return value to q, but does not use q again.

We followed removeSolveValidation() to isGraph(x) in lib/cjs/utils/is.js. This file contains checks such as isMatrix and isNumber. The added isGraph() function decrypts and loads code:

isGraph() converts its input to a JSON string and uses that string as a password. It first decrypts a filename. It then passes the file path and password to event(), and loads the returned path with require().

We have made the loader snippets easier to read by restoring strings and renaming local variables. The hashes at the end of this post identify the original files.

The matrix data becomes a password

In lib/cjs/utils/event.js, we found the decryption functions. They use scrypt to turn the password into a key of 256 bits. They then decrypt the data with Advanced Encryption Standard in Galois/Counter Mode (AES-GCM):

The encrypted data has a fixed layout: a salt of 16 bytes, an initialization vector of 12 bytes, and an authentication tag of 16 bytes. The ciphertext follows these fields. The package stores the whole sequence as base64 text.

For calls through the solver, the password is JSON.stringify(L._data). A caller can supply L through the object form of lusolve(). So the caller must pass matrix data that produces the correct password. We found no password stored in the visible loader.

The encrypted filename has eight bytes of ciphertext. We suspect it names graph.js, a file beside the loader whose name also takes eight bytes. We could not confirm this because we did not recover the password.

The loader writes and runs the file

The event() helper decrypts the file, writes the result to disk, and returns the output path:

If the filename has no enc_ prefix, the helper overwrites the encrypted file with the decrypted code. The require() call in isGraph() then loads it. That code would run with the same permissions as the Node.js process.

Three added files contain base64 data instead of normal JavaScript:

We found no reference to the last two files in the visible loader. The decrypted graph.js loads them as later stages, as the payload section shows.

We found no install hooks in the manifest. Importing the package through the path we reviewed does not activate the loader either. The solver must first pass its validation and calculation steps to reach the added call. If the password is wrong, validEvent() fails its authentication check before the helper writes any file.

The same loader appears in two more packages

We searched the npm registry and found two more packages: mathsbase and math-universe. Across five versions, we found identical loader files, trigger code, solver changes, and two large encrypted files.

The encrypted graph.js in [email protected] differs from the other copies. The shared files connect these releases. They do not tell us who added the loader or whether someone took over a publisher’s account.

On September 17, npm served [email protected] as the default release. That version did not contain this loader. Checking only the default version would have missed the code in 1.0.1.

On September 19, we checked npm’s download counts for all three packages. These totals cover September 12–18, 2026, across all versions of each package.

npm also reported zero downloads across the entire registry for September 17. This makes the earlier zero for mathmain unreliable. The packages have no public dependents. They have almost no traffic on the jsDelivr content network. So the counts do not show real installs. We could not determine what produced the volume. These counts do not tell us how many systems installed the packages or whether the encrypted code ran.

The loader is not in the GitHub source

The mathsbase and math-universe packages each link to a public GitHub repository. We read both. Neither repository holds the loader:

The public math-universe source ends its solver like this:

The extra removeSolveValidation() call is not there. The npm build has it. The GitHub source does not. So someone added the loader when they published the package, not in the public code.

We also looked for a program that calls the solver with the trigger. We searched GitHub code, lockfiles, and dependency services. We found none. Private projects, and code that search engines miss, stay out of reach.

Our first attempts did not find the password

We tested 16,922 possible passwords against the encrypted filename. Some came from matrices with zero diagonal entries, which our earlier search had left out.

In a second search, we tested 533 possible passwords against all five distinct encrypted blobs, including the older graph.js. We tried common passwords and numeric arrays from the solver’s tests. Neither search found a password that passed the authentication check.

Some passwords appeared in both searches.

We checked the tools with test data and known passwords. The searches finished. None of our guesses worked. The password was not a common value or a test matrix. It was one specific matrix that we found later.

Cracking the encryption

The password is the JSON form of a matrix lower factor L. JFrog first reported the input that produces it. We then reproduced the result against the mathmain files.

The recovered trigger is a 3 by 3 Pascal matrix.

A caller passes A to lusolve(). The solver runs an LU decomposition of A. The lower triangular factor L becomes [[1, 0, 0], [1, 1, 0], [1, 0.5, 1]]. The loader turns L into a JSON string. That string is the password.

We confirmed this against the real files. The password is the JSON form of L.

The password decrypted the filename to graph.js. It also decrypted the three payload files in mathmain and in math-universe. The mathmain payload matches the math-universe payload byte for byte. [email protected] uses the same password with different encrypted data. So the same password unlocks the whole family.

Payload analysis

The decrypted files form a small remote access implant. Each file has one job. The findings below come from our own static review of the decrypted code.

The decrypted graph.js is the first stage. The loader runs it with require() after decryption. It reads host data with os and fs. It generates an X25519 key pair with the Node crypto module through generateKeyPairSync and diffieHellman. It runs shell commands with child_process through spawn and execSync. It reads a smart contract on the Base Sepolia test network with a bundled copy of ethers. It reports to Slack chat.postMessage and to api.telegram.org. It then loads bignumber/type.js and fraction.js as later stages. The network details sit in the file as base64 text.

The decrypted bignumber/type.js is a copy of the ethers library. The file carries the marker ethers/5.7.2 and the JsonRpcProvider and secp256k1 symbols. The implant uses this library to read the smart contract.

The decrypted fraction.js is the command agent. It decrypts a Slack bot token and a channel id at run time. It needs a CHAT_PASSWORD value from the environment. Without that value, the agent exits. It polls the Slack conversations.history endpoint every 10 seconds. It checks whether a message comes from the operator. It then runs the message content as a shell command with execSync or spawn.

The package does not store the operator’s commands. The agent reads them from Slack at run time. So the live commands stay off the registry and out of our copy.

Together, these files let an operator run shell commands on any host that triggers the loader. The commands travel over a public chat service and a blockchain test network. The package is a remote access implant.

How the trigger reaches a victim

The loader stays inert until a caller runs the solver with an input that produces the factor L. A normal import does not reach the added code. A normal lusolve() call with other data fails the authentication check and writes nothing. The password is the JSON form of L, so the Pascal matrix is not the only trigger. A caller can pass L as the coefficient matrix, because its own lower factor is L again. A caller can also supply L through the object form of lusolve(). Both inputs give the same password.

The attack works in two parts. One package holds the encrypted payload. A second package, or a compromised caller, runs the solver with the trigger matrix. The math library looks like a popular, trusted dependency. The caller supplies the key.

We did not find that caller in public code. Our GitHub and dependency searches returned no project that calls the solver with the trigger. Private code and removed projects stay outside that search.

Investigation Timeline

All times are in Coordinated Universal Time (UTC). We took publication times from the npm registry metadata.

Indicators of compromise

Use these indicators to find the packages, the loader, and the decrypted implant. A match on a package or a hash does not prove the code ran on a host. A caller must first trigger the loader.

Malicious packages

SafeDep analyzed the loader in these versions. The archive SHA-256 comes from the npm tarball.

The trigger and the password

A caller activates the loader with one matrix. The password is the JSON form of that matrix LU lower factor.

Loader files

These two file hashes match across all analyzed versions.

Encrypted payload files

The base64 blobs sit under lib/cjs/utils/. [email protected] and the three math-universe versions share one set. [email protected] ships a different graph.js blob.

Decrypted payload files

These hashes cover the plaintext we recovered from Deployment A. A host where the loader ran may hold files with these hashes on disk.

Command and control

We recovered these endpoints from the decrypted graph.js files. Deployment A covers mathmain and math-universe. Deployment B covers [email protected]. We redact the secret half of the two bot tokens.

Both deployments use the same Alchemy project key D2-TbkB2m05WXSnSDOCDI. This key ties the two deployments to one operator.

• npm
• supply-chain
• package-analysis

Author

SafeDep Team

safedep.io

Share

The Latest from SafeDep blogs

Follow for the latest updates and insights on open source security & engineering

OpenAI Agents Turned RubyGems Into a Scraping Proxy

Between May and July 2026, a swarm of AI agents published over 3,000 packages to RubyGems. The gems abused RubyDoc.info documentation builds to run a crawler on someone else's servers, then shipped...

Deep-Live-Cam Supply Chain Attack: Technical Analysis

A malicious dependency in Deep-Live-Cam loads a clipboard hijacker. We trace the installation trigger, Telegraph delivery, and Windows and macOS persistence.

The Agentic IDE Extension Blind Spot

Cursor can install most of the same extensions you had in Visual Studio Code, but not the same versions. Its Import VS Code Configuration step sends only the extension name, never the version. It...

Introducing SafeDep Threat Intel

SafeDep Threat Intel gives SOC and cyber defense teams the malicious package intelligence behind SafeDep's platform, to query or to push into the tools they already run.

Ship Code.

Not Malware.

Start free with open source tools on your machine. Scale to a unified platform for your organization.