Bug Report — Wappler Node.js Local Server

Wappler General Bugs
, ,
1

Environment

Property Value
Wappler Version 7.9.2
OS macOS 15.7.5 Sequoia (arm64 / Apple Silicon)
Node.js Version v22.22.2
npm Version 11.12.1
Project Type Node.js (Server Connect)

Bug #1 — Server Shows "Running" in Wappler UI But ERR_CONNECTION_REFUSED in Browser

Summary

When a Wappler Node.js project's node_modules tree has a corrupted or incomplete nested dependency, the server crashes immediately on startup. However, Wappler's UI continues to display the server status as "Running", giving the developer no indication that anything is wrong. The browser returns ERR_CONNECTION_REFUSED with no explanation.

Severity

High — Completely blocks local development with no actionable feedback from the IDE.

Symptoms

  • Browser shows: This site can't be reached — localhost refused to connect (ERR_CONNECTION_REFUSED)
  • Wappler Server panel shows the server as Running (green indicator)
  • No error is shown in the Wappler UI
  • The correct URL (http://localhost:3020 in this case) returns nothing

Root Cause

Wappler starts the Node.js server via nodemon. It monitors the nodemon process as a proxy for server health. When node index.js crashes on startup (before binding to a port), nodemon stays alive but spawns no child process. Since nodemon itself is still running, Wappler incorrectly reports the server as active.

The specific crash in this case was a corrupted nested dependency:

node_modules/
  send/                          ← Express static file serving
    node_modules/
      debug/
        node_modules/
          ms/
            package.json         ✅ present
            license.md           ✅ present
            index.js             ❌ MISSING  ← crash here

Full error output (only visible by running node index.js manually in the terminal):

Error: Cannot find module '/Users/.../node_modules/send/node_modules/debug/node_modules/ms/index'.
Please verify that the package.json has a valid "main" entry
    at tryPackage (node:internal/modules/cjs/loader:502:19)
    at Module._findPath (node:internal/modules/cjs/loader:764:18)
    at Module._resolveFilename (node:internal/modules/cjs/loader:1369:27)
    ...
{
  code: 'MODULE_NOT_FOUND',
  path: '.../node_modules/send/node_modules/debug/node_modules/ms/package.json',
  requestPath: 'ms'
}

The affected packages:

  • send@0.19.2 (transitive dep of Express)
  • debug@2.6.9 (bundled inside send)
  • ms@2.0.0 (bundled inside debug inside send) — index.js was missing

Steps to Reproduce

  1. Create or open any Wappler Node.js project.
  2. Run npm install to install dependencies.
  3. Simulate corruption: rm node_modules/send/node_modules/debug/node_modules/ms/index.js
  4. Click Start Server in Wappler.
  5. Observe: Wappler shows Running (green). Browser shows ERR_CONNECTION_REFUSED.
  6. No error is surfaced in the Wappler UI.

How I Diagnosed It

Since Wappler gave no error feedback, I ran the server manually:

node index.js

This immediately printed the MODULE_NOT_FOUND error to the terminal — something Wappler never surfaced.

I also confirmed with:

lsof -i :3020  # No process was listening
ps aux | grep nodemon  # nodemon running, but no child node process
pgrep -P <nodemon_pid>  # Empty — no children

Fix / Workaround

rm -rf node_modules
npm install

This restored ms/index.js and the server started correctly, returning HTTP 200.

Suggested Fix for the Wappler Team

The Wappler server manager should monitor the actual child process spawned by nodemon, not nodemon itself. Specifically:

  1. Detect when the Node.js child process exits with a non-zero code immediately after launch (within ~2 seconds of starting) and update the status to :cross_mark: Crashed / Error.
  2. Capture and display stderr output from node index.js in the Wappler Server Log panel so developers can see crash messages without leaving the IDE.
  3. Alternatively, perform a health-check HTTP ping to localhost:<port> 3–5 seconds after "starting" and mark the server as failed if no response is received.

Bug #2 — High-Severity npm Security Vulnerability in Default Node.js Project Template

Summary

The default Wappler Node.js project template includes jsonpath as a direct dependency in package.json. This package depends on underscore <=1.13.7, which has a published high-severity CVE for a Denial of Service vulnerability. Running npm audit on any freshly generated Wappler Node.js project returns 2 high-severity vulnerabilities with no auto-fix available.

Severity

High — Security vulnerability shipped in the default project template, with no automated fix path via npm audit fix.

CVE Reference

  • Advisory: GHSA-qpx9-hpmf-5gmw
  • Package: underscore <= 1.13.7
  • Attack Type: Denial of Service via unlimited recursion in _.flatten() and _.isEqual()

npm audit Output (unmodified)

# npm audit report

underscore  <=1.13.7
Severity: high
Underscore has unlimited recursion in _.flatten and _.isEqual,
potential for DoS attack - https://github.com/advisories/GHSA-qpx9-hpmf-5gmw
No fix available
node_modules/underscore
  jsonpath  *
  Depends on vulnerable versions of underscore
  node_modules/jsonpath

2 high severity vulnerabilities

Some issues need review, and may require choosing a different dependency.

Root Cause

The Wappler-generated package.json includes jsonpath as a direct dependency:

"dependencies": {
    "jsonpath": "...",
    "jsonpath-plus": "^10.4.0",
    ...
}

Note that jsonpath-plus is already included as a separate dependency in the same template. jsonpath-plus has no known vulnerabilities and provides a superset of jsonpath's functionality. The jsonpath package is therefore redundant and introduces the vulnerability.

Where jsonpath Is Used in the Template

The only usage is in lib/modules/objectstructure.js:

// Line 2 — current (vulnerable)
const jsonpath = require('jsonpath');

// Line 62 — current (vulnerable)
return jsonpath.query(this.scope.data, expression);

Fix

Replace jsonpath with jsonpath-plus (already bundled). The APIs are equivalent for the .query() use case:

lib/modules/objectstructure.js — change line 2:

- const jsonpath = require('jsonpath');
+ const { JSONPath } = require('jsonpath-plus');

Change line 62:

- return jsonpath.query(this.scope.data, expression);
+ return JSONPath({ path: expression, json: this.scope.data });

Then remove jsonpath from package.json and uninstall:

npm uninstall jsonpath

Result after fix:

found 0 vulnerabilities

Why This Matters

  • Every new Wappler Node.js project ships with this vulnerability out of the box.
  • npm audit fix cannot resolve it automatically (the note says "No fix available" because underscore has no patched version that jsonpath can use).
  • Developers running security scans (CI/CD pipelines, GitHub Dependabot, etc.) will see these alerts immediately on a fresh project with no obvious path to resolution.

Suggested Fix for the Wappler Team

  1. Remove jsonpath from the default Node.js project template's package.json.
  2. Update lib/modules/objectstructure.js (in the Wappler Node.js runtime) to use jsonpath-plus, which is already included and actively maintained.
  3. Run npm audit as part of the Wappler project template QA process before each release to catch issues like this proactively.

Additional Notes

Both issues were discovered on a fresh npm install on an existing Wappler 7.9.2 Node.js project and are reproducible. Happy to provide additional diagnostic output or test a patched template if the team can share a pre-release build.

Hoping these can be addressed in the next update!

2

Extensive AI report, but it just seems you are missing some core files that are copied by the project updater, so run it and force update of all files.

3

AI (Claude OPUS 4.6) has fixed these issues. But every time I reopen Wappler or run Project Updater, it tries to replace those files with previous ones which had bugs.