NLP.js EUVD-2026-104166

Exploitation requires the host application to pass attacker-controlled input as the 'condition' argument into Evaluator.walkFunction (packages/evaluator/src/evaluator.js) within the Condition Expression Pipeline of NLP.js 4.27.0. The flaw is NOT reachable in a default standalone installation - it is only triggerable when the embedding application exposes the condition-expression evaluation path to untrusted data, and the CVSS vector further requires passive user interaction (UI:P). No patched version is available because the project has not yet responded to issue #1380, so the only mitigation is avoiding untrusted input in condition expressions.

This is a low-priority issue despite the attention-grabbing 'RCE'/'Code Injection' tags and CWE-94 classification. The vendor (VulDB) CVSS 4.0 vector scores only 2.1 with AV:N/AC:L/PR:N/UI:P and uniformly Low impacts (VC:L/VI:L/VA:L), signaling that although the flaw is network-reachable and unauthenticated, passive user interaction (UI:P) is required and the practical impact was judged limited. The exploitation signals are mixed: a public POC exists (VulDB github-poc zip) and exploitation status is 'publicly available exploit code exists', but there is NO CISA KEV listing and NO EPSS score was provided, so there is no evidence of active or widespread exploitation - the POC proves feasibility, not real-world use. A key conflict must be flagged: the CWE-94 code-injection classification and 'RCE' tag imply potentially high impact, yet VulDB rated all impact metrics Low - this discrepancy should be verified against the actual POC, because a Node.js expression evaluator that executes injected code could in some deployments yield far higher impact than the 2.1 score suggests. The dominant mitigating factor is that this is a library function: exploitation depends entirely on whether the embedding application routes untrusted input into the condition evaluator, which is not a default standalone condition.

An application built on AXA NLP.js 4.27.0 feeds user-supplied text into the Condition Expression Pipeline, and an attacker submits a crafted 'condition' argument that is passed to Evaluator.walkFunction, injecting executable code that the evaluator runs. A public POC (poc.zip) demonstrates the injection, so the technique is reproducible; impact is bounded by how the host application exposes and sandboxes the evaluator.