npm 수학 라이브러리에 암호화 로더가 숨겨진 이유

Back to Blog Why Does an npm Math Library Need an Encrypted Loader? Security SafeDep Team • Sep 18, 2026 • 11 min read On this page 11 sections On this page ` rules instead of the old inline `prose-* / [&_…]` modifier string — that string compiled to ~40 complex selectors that Chrome iOS (WKWebView) re-matched on every scroll recalc, blanking the page. Base `prose prose-lg prose-invert` reset is kept. Running text is capped at a readable measure in that file; code blocks, tables, and embeds intentionally span the full column. --> We found a remote access implant hidden inside [email protected] , an npm package that copies the popular mathjs library. The malicious code ships encrypted. It stays dormant until a program solves a specific equation with the library. That equation is the key. When the key matches, the package decrypts a payload and runs it. The payload takes commands from the attacker and runs them on the host. It uses a public chat service and a blockchain network for its command channel. This post shows how we found the loader, how we decrypted it, what the payload does, and the indicators you can use to find it. 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: Path under lib/cjs/utils/ Size of ciphertext in bytes graph.js 20,918 fraction.js 9,084 bignumber/type.js 1,179,416 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. Package Reported downloads mathmain 605,157 mathsbase 1,923,059 math-universe 569,730 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: Repository Reviewed commit github[.]com/tinystar8/mathsbase 560d97e66140dbf817e04284a7a0c58757d1202e github[.]com/mathubio/math-universe da99dd46501c75ba6102a51ef60ebb922174da32 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 analys