CVE-2022-43285 caught the eye of security researchers in 2022—it reportedly describes a segmentation violation in the Nginx NJS JavaScript engine, specifically in the njs_promise_reaction_job function. Here’s the thing: the Nginx team disputes the real-world impact of this bug. In this long-read, I’ll walk you through:

1. What is NJS and Where Does It Fit?

First, some context. NJS is a “subset of JavaScript for NGINX”, letting you write request or response handling scripts. It is used for things like manipulating requests, filtering responses, etc. NJS isn’t some full browser JS runtime; it’s meant for internal use in Nginx server blocks.

2. Where is the Issue?

A security researcher discovered that calling certain Promise operations in NJS v.7.4 could cause a segmentation fault (aka “segfault” or SIGSEGV) in the function njs_promise_reaction_job. In plain English, this means: under some conditions, you might crash the NGINX worker process by running weird JavaScript.

The original report can be found on GitHub.

Here’s a simplified version—in pseudocode—of how a crash might happen

// Example: This script, if run in NJS context, could trigger a crash
let a = Promise.resolve(1);
a.then(() => {
    // Circular promise chain, which leads to double free or segfault
    return a;
});

In the actual C source code of njs_promise_reaction_job, poor handling of circular or recursive promise chains can make the process access or free wrong memory, causing a crash.  

Here is an extract from the NJS source:

static njs_int_t
njs_promise_reaction_job(njs_vm_t *vm, njs_value_t *args, ... )
{
    // ... Omitted for brevity
    if (promise_chain_is_recursive) {
        // Potential faulty code path
        /* later can result in segfault */
    }
}



These segfaults are not “arbitrary code execution” vulnerabilities. They're denial of service (DoS): crash the worker, interrupt traffic until it restarts.

3. Why Is the CVE Disputed?

The Nginx team said: yes, the crash can happen—but the bug only triggers if *trusted code* (NJS code) runs in the process. Since NJS code is typically written and deployed by the server admin (that’s you or your devops team, not a random attacker), the NGINX maintainers don’t consider this a practical security issue.

From their GitHub comment

> “NJS does not operate on untrusted input: only trusted code provided by the Nginx administrator is executed.”

So: if nobody but admins can change/submit NJS scripts on your server, an attacker can’t trigger the crash.

Simulating an Exploit in Developer Setup

If an attacker *could* upload or run arbitrary NJS scripts (e.g., if your deployment allows users to provide their own NJS scripts for some reason, which is rare), exploitation is trivial. Here’s a simulated proof-of-concept:

PoC for Crash  

// Run in your NJS environment
var p = Promise.resolve();
var q = p.then(() => q);  // Circular reference

Result: The NGINX worker process running that code will hit a segmentation fault and crash.

Mitigations:

You are at risk only if

- External, potentially untrusted users can run or supply custom NJS scripts on your server (very rare!).

You are not at risk if

- Only sysadmins/developers can change NJS scripts.

You do not use NJS at all.

If you’re still concerned, upgrade to a newer NJS version or check that your configuration restricts NJS script access.

6. References & Further Reading

- CVE entry: CVE-2022-43285
- Nginx NJS bug tracker issue #543 (GitHub) – Original report, PoC, vendor comments
- NJS official docs – What NJS is & how it works

7. TL;DR

- CVE-2022-43285 is a segfault bug when running odd Promise chains in Nginx’s NJS engine (before v.7.4).

Only NJS code can trigger this, and server admins alone control what NJS code runs.

- The bug cannot be triggered by malformed HTTP requests or external users—unless your setup is very non-standard.

Still, best practice: upgrade and never let untrusted users run NJS code on your servers.

Have questions? Ask in the NGINX NJS GitHub Issues or Nginx Forum.

Timeline

Published on: 10/28/2022 21:15:00 UTC
Last modified on: 12/08/2022 18:00:00 UTC