Infinite Loops & Broken Dreams: The fast-xml-parser Stack Exhaustion

Every developer loves a fast library. fast-xml-parser sells itself on speed and efficiency, and for the most part, it delivers. But as with most things in the JavaScript ecosystem, the devil is in the loosely-typed details. The vulnerability lies within the XMLBuilder component, specifically when a user enables the preserveOrder: true option.

When this option is on, the builder stops treating your input JSON as a chaotic bag of properties and starts expecting a very specific, orderly structure—typically an array of objects. It needs this structure to respect the order of XML tags during generation.

This is where things get interesting. The code assumes that if you are preserving order, you are playing by the rules and providing arrays. It blindly trusts the structure. And as any security researcher knows, blind trust is just a polite way of saying "please exploit me."

The root cause is a logic error in src/xmlbuilder/orderedJs2Xml.js inside a function called arrToStr. This function is responsible for traversing the ordered array structure and converting it to an XML string. It uses recursion to handle nested tags, which is standard practice for tree traversal.

However, the function lacked a critical safety check: a base case for invalid types. It assumed the input arr was always an Array. In JavaScript, strings and arrays share some dangerous similarities—specifically, they both have a length property and can be indexed (val[0]).

If an attacker passes a string where the code expects an array, the function loops over the string's length. Inside that loop, it grabs the character at index i (which is a string of length 1) and recursively calls itself with that character.

Here is the punchline: A string of length 1 (e.g., 'a') has a length of 1. The loop runs once. It grabs index 0, which is... 'a'. It recurses again. The function essentially creates a logic Ouroboros—a snake eating its own tail—looping infinitely until the V8 engine runs out of stack space and screams.

Let's look at the smoking gun. This is the code before the fix. Notice the immediate entry into a for loop based on .length without verifying what arr actually is.

// VULNERABLE CODE
function arrToStr(arr, options, jPath, indentation) {
    let xmlStr = "";
    // ... setup ...
 
    // The Fatal Assumption: "arr" is definitely an array, right?
    for (let i = 0; i < arr.length; i++) {
        let tagObj = arr[i]; 
        // ... processing ...
        // Recursive call happens later based on tagObj
    }
    return xmlStr;
}

And here is the fix implemented in version 5.3.8. The developers added a sanity check right at the front door. If arr isn't an array, it treats it as a primitive value (text) and returns, effectively creating the missing base case for the recursion.

// PATCHED CODE (Commit c13a961)
function arrToStr(arr, options, jPath, indentation) {
    // The Fix: Explicitly check types before looping
    if (!Array.isArray(arr)) {
        if (arr !== undefined && arr !== null) {
           return arr.toString(); // Treat as text content
        }
        return "";
    }
 
    for (let i = 0; i < arr.length; i++) {
        // Now safe to loop
    }
}

Exploiting this is trivially easy if you can control the object passed to the builder. This often happens in web applications that accept JSON configurations or data exports and convert them to XML for legacy system compatibility.

An attacker simply needs to construct a JSON object where a node that should be an array is replaced with a string. Because preserveOrder: true changes the parsing logic to expect arrays, the mismatch triggers the flaw.

Here is the Proof of Concept:

const { XMLBuilder } = require('fast-xml-parser');
 
// 1. Enable the vulnerable setting
const builder = new XMLBuilder({ preserveOrder: true });
 
// 2. Craft the poison payload
// The builder expects children of 'foo' to be arrays of objects.
// We give it a string inside a nested object.
const poison = [{
    'root': [
        { 'nested': "I am a string, not an array!" }
    ]
}];
 
console.log("Attempting to build...");
 
// 3. Trigger the stack overflow
try {
    builder.build(poison);
} catch (e) {
    console.log("Crash confirmed:", e.message);
    // Output: RangeError: Maximum call stack size exceeded
}

When this runs, the process terminates. In a production Node.js environment (which is single-threaded), this means the server stops handling all requests until the process manager restarts it. A persistent attacker can keep the service flapping indefinitely.

You might look at the CVSS score of 2.7 and think, "I'll patch this next quarter." That would be a mistake. While this vulnerability doesn't allow for Remote Code Execution (RCE) or data exfiltration, availability is a key pillar of the CIA triad.

Modern microservices often rely on these utility libraries for data transformation. If you have a public-facing endpoint that converts JSON to XML (e.g., an export feature or a SOAP integration bridge), a single malformed request can take down the pod or container.

If you are running a serverless function (like AWS Lambda), this will cause the invocation to timeout or error out, potentially racking up costs or triggering error alarms that wake up your on-call engineer at 3 AM. Low severity, high nuisance.

The path forward is straightforward. The maintainers released a patch quickly after disclosure.

Immediate Action: Upgrade fast-xml-parser to version 5.3.8 or higher.

If you cannot upgrade immediately (perhaps you are stuck in dependency hell), you have two mitigation options:

1. Disable preserveOrder: If your application logic doesn't strictly require ordered XML tags, set this option to false. The vulnerable code path is completely skipped in the default mode.
2. Strict Input Validation: Before passing data to the builder, validate strictly that the structure matches the schema you expect using a library like Joi or Zod. Ensure arrays are actually arrays.