The Ghost in the Machine: How an Empty Number Killed the Node.js Event Loop

JavaScript has a complicated relationship with numbers. For years, we were stuck with IEEE 754 doubles, meaning anything integer-like above $2^{53}$ was a gamble. Enter bn.js, the unsung hero of the ecosystem. It is the bedrock for elliptic curve cryptography, blockchain implementations, and basically anything in Node.js that needs to count higher than a standard database ID.

But here's the thing about foundational libraries: when they crack, the tremors are felt everywhere. CVE-2026-2739 isn't a buffer overflow or a remote code execution via some complex gadget chain. It's a logic bug. A simple, stupid logic bug that turns a mathematical operation into a weapon of mass thread-destruction.

This vulnerability exploits the internal representation of these big numbers. By asking the library to perform a specific bitwise operation—masking a number with zero bits—we can trick the object into an invalid state. It creates a number that technically exists but has no data. When the library tries to read this 'ghost' number, it panics, loops, and takes your server down with it.

To understand the bug, you have to look under the hood of bn.js. Since JavaScript didn't support 64-bit integers natively for a long time, bn.js implements numbers as an array of 'words' (usually 26-bit chunks) and a length property tracking how many words are in use.

The Invariant: The library relies on a strict invariant: length must always be at least 1. Even the number 0 is represented as words: [0], length: 1. There is no such thing as a number with no words.

The Glitch: The vulnerability lies in maskn(bits) (and imaskn). This function is supposed to keep only the lowest n bits of the number. The logic calculates how many words are needed to hold those bits and truncates the rest.

However, the developers forgot a critical edge case: maskn(0). When you ask for the lowest 0 bits, the calculation effectively wipes the array. Prior to version 5.2.3, this operation would set this.length = 0.

Congratulations. You have created a zombie object. It is a BN instance that violates the fundamental laws of its own universe. It has no length. It is a void.

The fix is almost insultingly simple, which is characteristic of the most dangerous bugs. The developers just needed to ensure that if the masking operation wipes the number clean, it resets to the canonical 'zero' state rather than the 'void' state.

Here is the diff from the patch. Note the explicit check for the zero-length condition:

// lib/bn.js
 
   BN.prototype.imaskn = function imaskn(bits) {
     // ... existing logic truncating words ...
 
     // The Vulnerable State: words might be empty now.
+    // The Fix: Force it back to a valid Zero.
+    if (this.length === 0) {
+      this.words[0] = 0;
+      this.length = 1;
+    }
 
     return this._strip();
   };

Without this guard clause, this.length remains 0. The _strip() method, which is supposed to remove leading zero words, assumes there is at least one word to check. When length is 0, the internal logic of downstream functions collapses.

You don't need Metasploit for this. You don't need heap spraying. You just need a Node.js console. The exploitation is trivial because the corruption happens silently. The crash doesn't occur when you create the bad number; it happens when you try to look at it.

The PoC:

const BN = require('bn.js');
 
// Step 1: Create a perfectly normal number
const target = new BN('123456');
 
// Step 2: Corrupt it. 
// We ask for the lowest 0 bits. Theoretically, this is 0.
// Practically, it creates an invalid object.
target.maskn(0);
 
// Step 3: Trigger the infinite loop.
// toString() relies on length to iterate. 
// With length 0, the loop condition is never met or underflows.
console.log("Goodbye, Event Loop...");
target.toString(); 

Why toString() hangs: The toString method usually performs repeated division and modulo operations to convert the number base (e.g., base 10). These algorithms loop while (number > 0). Because the internal state is corrupted (length: 0), the comparison logic fails to report '0', or the division step produces a result that doesn't reduce the problem size, resulting in an infinite while(true) scenario.

In a threaded environment like Java or C++, a CPU-spinning infinite loop is bad, but it usually only kills one worker thread. The rest of the application limps on.

Node.js is single-threaded. It runs on an event loop. If any operation blocks that loop—like a while(true) caused by a corrupt BigNumber—the entire process stops. It stops accepting HTTP requests. It stops processing database callbacks. It stops responding to health checks.

Attack Vectors:

1. Smart Contracts/dApps: Many dApps use bn.js to handle token amounts. If a user can pass a parameter that results in a bit-mask of 0, they can freeze the processing node.
2. Cryptography Handlers: If an implementation derives a mask length from user input (e.g., "give me the last N bits of this key"), sending N=0 triggers the DoS.
3. Data Serialization: JSON endpoints that accept big integers and perform transformations before saving them are prime targets.

If you are running bn.js < 5.2.3, you are vulnerable. The dependency tree of the average Node project is deep and dark; you might not even know you are using it. elliptic, web3.js, and asn1.js all rely on it.

Remediation:

1. Update Direct Dependencies: npm install bn.js@latest.
2. Audit Transitive Dependencies: Use npm audit or yarn audit. You will likely need to regenerate lockfiles to force nested dependencies to grab the patched version.
3. Defensive Coding: If you cannot update immediately, sanitize inputs. Never pass 0 to a bitwise mask function.

// The monkey-patch band-aid
const BN = require('bn.js');
const originalMaskn = BN.prototype.maskn;
BN.prototype.maskn = function(bits) {
  if (bits === 0) return new BN(0);
  return originalMaskn.apply(this, arguments);
};

This is a classic example of why input validation is hard—sometimes the invalid input (0) looks perfectly harmless.