GHSA-JF75-Q64Q-G65R
Vulnerability from github – Published: 2026-10-28 21:17 – Updated: 2026-10-28 21:17Summary
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.
Details
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.
## Proof of Concept
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>"}
- Because `email` is not a string, parseWhere adds nothing for it, so the query filter is {} and MongoDB returns all users.
- user[0] — the first-registered user, i.e. the administrator — is selected, and the submitted password is checked against the administrator's hash.
- If the password matches (for example via credential stuffing or a known/weak password), the attacker is authenticated as the administrator without ever knowing the administrator's email.
- Even when the password does not match, the request confirms that users exist (enumeration) and that the email factor is bypassable.
## Impact
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:
- enables user enumeration;
- amplifies credential stuffing against the administrator (no need to know the admin email — a leaked or weak password can be tested directly);
- and, when the attacker possesses a valid password for that account (e.g. a reused/breached one), results in administrator login.
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.)
## Remediation
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.40.3"
},
"package": {
"ecosystem": "npm",
"name": "@waline/vercel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.41.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-943"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-28T21:17:58Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe 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\u0027s 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 \u2014 the site administrator.\n\nThis 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 \u2014 an attacker can test a leaked or weak password against the administrator account without knowing the administrator\u0027s email.\n\n## Details\n\nUntyped input \u2014 packages/server/src/controller/token.js:17-18:\n```\n const { email, password, code } = this.post();\n const user = await this.modelInstance.select({ email });\n````\n`email` comes from the request body with no type check.\n\nThe storage adapter silently drops a non-string key \u2014 packages/server/src/service/storage/mongodb.js, parseWhere():\n```\n if (think.isString(where[k])) { filter[parseKey(k)] = { $eq: ... }; continue; } // intended guard\n if (where[k] === undefined) { ... }\n if (Array.isArray(where[k]) \u0026\u0026 where[k][0]) { ... operator handling (IN/LIKE/!=/\u003e ...) }\n```\nA 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 = {} -\u003e instance.where({}) -\u003e MongoDB find({}) returns every user. (The array form, e.g. [\"!=\", \"\"], is a genuine operator injection that reaches $ne with the same match-all effect.)\n\nFirst user is selected \u2014 token.js:22-26:\n```\n if (think.isEmpty(user) || isVerifyUser || isBannedUser) { return this.fail(); } // match-all -\u003e not empty -\u003e passes\n const checkPassword = this.checkPassword(password, user[0].password);\n```\nuser[0] is the first record in MongoDB natural (insertion) order, i.e. the earliest-registered user, which in Waline is the administrator.\n\nNo upstream type validation \u2014 packages/server/src/logic/token.js:37-38:\n```\n async postAction() { await this.useCaptchaCheck(); }\n```\nThe only pre-check is the captcha; there is no isString(email/password) validation.\n\n## Proof of Concept\n\nSend a login request whose email is a non-string value:\n```\n POST /api/token HTTP/1.1\n Content-Type: application/json\n\n {\"email\": {\"$ne\": null}, \"password\": \"\u003cpassword-to-test\u003e\"}\n```\n- Because `email` is not a string, parseWhere adds nothing for it, so the query filter is {} and MongoDB returns all users.\n- user[0] \u2014 the first-registered user, i.e. the administrator \u2014 is selected, and the submitted password is checked against the administrator\u0027s hash.\n- If the password matches (for example via credential stuffing or a known/weak password), the attacker is authenticated as the administrator without ever knowing the administrator\u0027s email.\n- Even when the password does not match, the request confirms that users exist (enumeration) and that the email factor is bypassable.\n\n## Impact\n\nAn 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:\n- enables user enumeration;\n- amplifies credential stuffing against the administrator (no need to know the admin email \u2014 a leaked or weak password can be tested directly);\n- and, when the attacker possesses a valid password for that account (e.g. a reused/breached one), results in administrator login.\n\nThis 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.)\n\n## Remediation\n\nValidate the types of `email` and `password` as strings before they reach the storage query \u2014 for example in packages/server/src/logic/token.js postAction():\n```\n const { email, password } = this.post();\n if (!think.isString(email) || !think.isString(password)) {\n return this.ctx.throw(400, \u0027Invalid input type\u0027);\n }\n```\nDefense 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.",
"id": "GHSA-jf75-q64q-g65r",
"modified": "2026-10-28T21:17:58Z",
"published": "2026-10-28T21:17:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/walinejs/waline/security/advisories/GHSA-jf75-q64q-g65r"
},
{
"type": "WEB",
"url": "https://github.com/walinejs/waline/pull/3646"
},
{
"type": "WEB",
"url": "https://github.com/walinejs/waline/commit/e611aed4e571c2a86103f5cee48791ca6b460360"
},
{
"type": "PACKAGE",
"url": "https://github.com/walinejs/waline"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Waline login accepts a non-string email as a match-all MongoDB query"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.