Live › vulnerability › GHSA-jf75-q64q-g65r
Go to dashboardWaline's login endpoint passes the request's email field to a MongoDB query without checking its type, so a JSON object like {"$ne": null} is dropped and matches all users. The password is then checked against the first-registered user, usually the site administrator, which lets an attacker test passwords against that account without knowing its email.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 21:22 UTC. All times on this page are UTC.
Deployments that run @waline/vercel at version 1.40.3 or earlier are exposed through the POST /api/token login endpoint. The flaw is in the MongoDB storage path, so deployments on other storage are less clearly affected and the sources do not say. Teams already on 1.41.0 or later can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| @waline/vercel | npm | <= 1.40.3 | 1.41.0 |
npm ls @waline/vercel in the project and look for a version at or below 1.40.3.package-lock.json, pnpm-lock.yaml or yarn.lock) for @waline/vercel versions at or below 1.40.3.@waline/vercel to 1.41.0 or later.1.41.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
The login endpoint POST /api/token reads the email field from the request body without checking its type and passes it straight into the MongoDB storage query. When email is not a string (for example a JSON object such as {"$ne": null}), the MongoDB storage adapter's parseWhere silently DROPS the field rather than rejecting the request, producing an empty filter that matches ALL users. The endpoint then verifies the submitted password against the FIRST user returned (user[0]), which in Waline is the first-registered user — the site administrator.
This is a PARTIAL authentication bypass, not a full one. The attacker still needs a valid password for that first user; this is not a zero-knowledge bypass and it does not disclose passwords. Its concrete effects are: (1) the email/identifier factor is removed for the administrator account, (2) user enumeration (a non-string email never fails the "no such user" branch), and (3) credential-stuffing amplification — an attacker can test a leaked or weak password against the administrator account without knowing the administrator's email.
Untyped input — packages/server/src/controller/token.js:17-18:
const { email, password, code } = this.post();
const user = await this.modelInstance.select({ email });
email comes from the request body with no type check.
The storage adapter silently drops a non-string key — packages/server/src/service/storage/mongodb.js, parseWhere():
if (think.isString(where[k])) { filter[parseKey(k)] = { $eq: ... }; continue; } // intended guard
if (where[k] === undefined) { ... }
if (Array.isArray(where[k]) && where[k][0]) { ... operator handling (IN/LIKE/!=/> ...) }
A plain object such as {"$ne": null} is neither a string, undefined, nor an array, so NONE of the branches run and nothing is added to filter for email. The result is filter = {} -> instance.where({}) -> MongoDB find({}) returns every user. (The array form, e.g. ["!=", ""], is a genuine operator injection that reaches $ne with the same match-all effect.)
First user is selected — token.js:22-26:
if (think.isEmpty(user) || isVerifyUser || isBannedUser) { return this.fail(); } // match-all -> not empty -> passes
const checkPassword = this.checkPassword(password, user[0].password);
user[0] is the first record in MongoDB natural (insertion) order, i.e. the earliest-registered user, which in Waline is the administrator.
No upstream type validation — packages/server/src/logic/token.js:37-38:
async postAction() { await this.useCaptchaCheck(); }
The only pre-check is the captcha; there is no isString(email/password) validation.
Send a login request whose email is a non-string value:
POST /api/token HTTP/1.1
Content-Type: application/json
{"email": {"$ne": null}, "password": "<password-to-test>"}
email is not a string, parseWhere adds nothing for it, so the query filter is {} and MongoDB returns all users.An unauthenticated attacker can bypass the email/identifier factor of authentication for the first-registered user (the administrator) and have an arbitrary password checked directly against that account. This:
This is bounded: it is NOT a zero-knowledge authentication bypass, it does NOT reveal passwords, and it targets the first-returned user rather than an arbitrary chosen account. It is rated Medium accordingly. (If exploitation succeeds in logging in, the attacker then holds the administrator session; that downstream impact is conditional on already having a valid password, which is reflected in the High attack complexity rather than in the confidentiality/integrity metrics.)
Validate the types of email and password as strings before they reach the storage query — for example in packages/server/src/logic/token.js postAction():
const { email, password } = this.post();
if (!think.isString(email) || !think.isString(password)) {
return this.ctx.throw(400, 'Invalid input type');
}
Defense in depth: in mongodb.js parseWhere(), reject (rather than silently drop) a value that is neither a string nor a supported array form, or coerce it to {$eq: String(value)}, so a non-string key can never elide the filter.
This page as .md · .json · in your agent: get_signal("GHSA-jf75-q64q-g65r")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.