GHSA-jf75-q64q-g65r: NoSQL Query Manipulation and Partial Authentication Bypass in Waline Server

Waline is an open-source comment system featuring a server component (@waline/vercel, located in packages/server of the walinejs/waline monorepo) built on top of the ThinkJS Node.js framework. The server supports multiple database backends—including SQLite, MySQL, PostgreSQL, and MongoDB—through custom storage adapter services. User authentication for comment moderation and site administration is handled via the POST /api/token REST endpoint, which processes inbound JSON credentials and issues JSON Web Tokens (JWTs) upon successful verification.

In @waline/vercel versions 1.40.3 and earlier, the authentication routine exhibits an improper authentication weakness (CWE-287) coupled with improper neutralization of special elements in data query logic (CWE-943). Specifically, the TokenLogic and TokenController modules accept deserialized JSON parameters from the request body without verifying that the email field is a primitive string before passing it to the database abstraction layer.

When the application is configured to use MongoDB as its backing store, passing a non-string value—such as a nested JSON object ({"$ne": null}) or a two-element array (["!=", ""])—alters the query construction behavior inside packages/server/src/service/storage/mongodb.js. If an arbitrary object is supplied, the query builder fails to match any expected type branch and silently drops the email filter key, resulting in an empty MongoDB filter ({}). If a formatted array is supplied, the adapter translates it into an explicit inequality filter.

Executing an unconstrained db.users.find({}) query returns the entire collection of registered users in natural insertion order. Because the login controller unconditionally evaluates the password hash against the first element of the result array (user[0]), and because Waline assigns administrator privileges to the first registered user during initial setup, any authentication attempt using a non-string email parameter deterministically targets the site administrator account. This eliminates the requirement for an attacker to discover the administrator's email address prior to conducting password guessing or credential stuffing attacks.

The root cause of GHSA-jf75-q64q-g65r spans three distinct layers of the Waline server architecture: missing type validation in the ThinkJS logic layer, permissive fallback behavior in the MongoDB storage service's query parser, and unsafe array indexing in the authentication controller.

In ThinkJS applications, incoming request validation is handled by a Logic class that executes prior to the corresponding Controller action. Prior to version 1.41.0, the postAction() method in packages/server/src/logic/token.js only invoked await this.useCaptchaCheck() and defined no schema rules (this.rules) for the request payload. When a client sends an HTTP POST request with Content-Type: application/json, the framework's body parser deserializes the payload into native JavaScript types. Consequently, this.post() in packages/server/src/controller/token.js extracts email regardless of whether it is a string, object, or array, and passes { email } directly to this.modelInstance.select({ email }).

Within the MongoDB storage adapter (packages/server/src/service/storage/mongodb.js), the parseWhere() method iterates over the properties of the where object to construct a MongoDB filter dictionary. For each key k, the method checks three primary conditions:

1. if (think.isString(where[k])): Appends a strict equality match { $eq: where[k] } to the filter.
2. if (where[k] === undefined): Skips the field.
3. if (Array.isArray(where[k]) && where[k][0]): Parses custom query operators such as IN, LIKE, !=, or comparison operators.

There is no else branch or type assertion to reject unexpected data types. When an attacker provides a plain JavaScript object such as {"email": {"$ne": null}}, all three conditional checks evaluate to false. The loop completes without adding an email key to the filter object, causing the adapter to execute instance.where({}) against the MongoDB collection. Alternatively, if the attacker supplies a two-element array such as ["!= ", ""], the third branch is entered, translating the input into a MongoDB inequality query that similarly matches all user documents.

Once select() returns the full array of user documents from MongoDB, TokenController.postAction() checks if (think.isEmpty(user) || isVerifyUser || isBannedUser). Because at least one user exists in an initialized instance, think.isEmpty(user) evaluates to false. The controller then immediately executes this.checkPassword(password, user[0].password), implicitly assuming that a query on a unique email attribute could only return a single matching user record.

Examining the vulnerable implementation across the controller and storage layers illustrates how untyped input propagates into database query execution. In packages/server/src/controller/token.js, the controller retrieves request parameters and queries the user model without defensive checks on the parameter types or the cardinality of the returned result set:

// packages/server/src/controller/token.js (Vulnerable Path)
const { email, password, code } = this.post();
// If email is an object, { email } passes an object into the query builder
const user = await this.modelInstance.select({ email });
 
if (think.isEmpty(user) || isVerifyUser || isBannedUser) {
  return this.fail();
}
 
// Unconditionally selects the first document returned by the database
const checkPassword = this.checkPassword(password, user[0].password);

When this.modelInstance.select({ email }) is invoked on a MongoDB-backed deployment, execution reaches parseWhere() in packages/server/src/service/storage/mongodb.js:

// packages/server/src/service/storage/mongodb.js
if (think.isString(where[k])) {
  filter[parseKey(k)] = { $eq: where[k] };
  continue;
}
if (where[k] === undefined) {
  // skip undefined fields
}
if (Array.isArray(where[k]) && where[k][0]) {
  // operator handling (IN / LIKE / != / > ...)
}
// Missing fallback: Objects fall through silently without modifying `filter`

In commit e611aed4e571c2a86103f5cee48791ca6b460360 (Pull Request #3646), the maintainers remediated the vulnerability at the validation boundary in packages/server/src/logic/token.js. By defining this.rules inside TokenLogic.postAction(), ThinkJS intercepts the request before TokenController.postAction() is invoked:

--- a/packages/server/src/logic/token.js
+++ b/packages/server/src/logic/token.js
@@ -35,6 +35,17 @@ module.exports = class TokenLogic extends Base {
    * @apiSuccess (200) {String}  errmsg  return error message if error
    */
   async postAction() {
+    this.rules = {
+      email: {
+        required: true,
+        email: true, // Enforces string type and valid email format
+      },
+      password: {
+        required: true,
+        string: true, // Enforces string type for password
+      },
+    };
+
     await this.useCaptchaCheck();
   }

> [!NOTE] > Assessment of Fix Completeness: The patch in packages/server/src/logic/token.js effectively prevents GHSA-jf75-q64q-g65r on the POST /api/token endpoint because ThinkJS's email: true validator strictly requires the value to be a string matching a standard email regular expression. Non-string inputs (objects, arrays, numbers) immediately trigger validation error 1001 before reaching the controller or storage layer. However, the underlying parseWhere() implementation in packages/server/src/service/storage/mongodb.js was not modified in commit e611aed4e571c2a86103f5cee48791ca6b460360. Consequently, any other controller endpoint that passes unvalidated user input directly to modelInstance.select(), update(), or delete() without corresponding Logic rules remains susceptible to similar filter-dropping or array-operator injection behavior when running on MongoDB.

Exploiting GHSA-jf75-q64q-g65r requires network access to the Waline server's HTTP API (POST /api/token) and requires that the target instance is configured to use MongoDB as its database provider (configured via MONGO_DB environment variables). No prior authentication, session tokens, or knowledge of registered user email addresses is required.

To trigger the match-all query, an attacker sends an HTTP POST request with a Content-Type: application/json header where the email field is set to a JSON object instead of a string. A minimal proof-of-concept request takes the following form:

POST /api/token HTTP/1.1
Host: target-waline-instance.example.com
Content-Type: application/json
Accept: application/json
 
{
  "email": {
    "$ne": null
  },
  "password": "CandidatePassword123!"
}

Note that because parseWhere() ignores all non-array objects, the contents of the email object do not need to be valid MongoDB operators; even an empty JSON object ("email": {}) will cause think.isString() and Array.isArray() to return false, resulting in the exact same empty {} filter query against the Users collection.

When the server processes this payload, three distinct operational impacts occur:

1. Bypassing the Non-Existent User Branch: Under normal operation with an unknown email string, select({ email }) returns an empty array [], causing think.isEmpty(user) to return true and immediately terminating the request before password hashing occurs. With `

The severity of GHSA-jf75-q64q-g65r is rated as Medium with a CVSS v3.1 base score of 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). The vulnerability is exploitable over the network (AV:N) with low attack complexity (AC:L), requiring no privileges (PR:N) and no user interaction (UI:N).

The primary security impact is the degradation of the authentication mechanism from a two-factor knowledge requirement (valid administrator email address + valid administrator password) to a single-factor requirement (valid administrator password only). In standard Waline deployments, administrator email addresses may not be publicly exposed if the administrator does not post public comments or if email hashes are obfuscated. By forcing the backend to query db.users.find({}) and select user[0], an attacker deterministically targets the primary administrator account created during system initialization.

Furthermore, this flaw enables unauthenticated user state discovery and brute-force amplification. By observing response timings and status codes when submitting {"email": {"$ne": null}}, an attacker can confirm whether the target Waline instance uses MongoDB and has at least one active, verified, non-banned user account (as BCrypt password verification via this.checkPassword() is only executed when user[0] exists and passes verification/ban checks). If an attacker successfully guesses or stuffs the administrator's password, the /api/token endpoint returns a valid JWT signed with the server's JWT_TOKEN secret.

Possession of an administrator JWT grants complete control over the Waline comment moderation interface. An authenticated administrator can read private user metadata (including real email addresses and IP addresses of all commenters), approve or delete arbitrary comments, modify user roles, and ban legitimate users, resulting in measurable impacts to both application confidentiality (C:L) and data integrity (I:L).

Site operators and developers using Waline must upgrade the server package @waline/vercel to version 1.41.0 or later. Version 1.41.0 incorporates commit e611aed4e571c2a86103f5cee48791ca6b460360, which enforces strict schema validation on POST /api/token via ThinkJS Logic rules, ensuring that requests containing missing, non-string, or improperly formatted email or password parameters are rejected with error code 1001 prior to database query generation.

To upgrade a standard deployment managed via npm, run the following command and redeploy the serverless function or Node.js container:

npm install @waline/vercel@^1.41.0

For organizations maintaining custom forks of walinejs/waline or custom ThinkJS storage adapters, two defense-in-depth measures are recommended beyond applying the TokenLogic rules:

1. Strict Type Enforcement in parseWhere(): Modify packages/server/src/service/storage/mongodb.js so that unrecognized data types (such as plain objects or booleans) throw an explicit exception or coerce values to strings rather than silently omitting the key from the MongoDB filter object.
2. Enable Captcha and Rate Limiting: Configure Waline's built-in Captcha verification (TURNSTILE_KEY / RECAPTCHA_V3_KEY) and deploy upstream rate limiting on /api/token to mitigate automated credential stuffing against the authentication endpoint.

If immediate patching is not feasible, administrators can deploy a Web Application Firewall (WAF) or reverse proxy rule to inspect inbound POST bodies directed at /api/token and block requests where the email attribute contains nested JSON objects ({...}) or arrays ([...]).