Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-55369medium6.5

Waline login accepts a non-string email as a match-all MongoDB query

Impact

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.

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

Affected range Recorded fix
Earlier releases before 1.41.0Semantic versions1.41.0

Version evidence: OSV · GHSA-jf75-q64q-g65r

View original version evidence (0 explicit versions)

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

walinejs · GitHub_M

waline

1 range

Compare with this publisher’s ranges. This does not inspect your installation.

affected

<= 1.40.3

unaffected

unknown

Other versions: unknown

Original source description

Summary

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.

Inside the record

Evidence available

Package identity
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers · not supplied

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-55369

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-287 ↗

CWE-287: Improper Authentication

GitHub_M

Related →
CWE-943 ↗

CWE-943: Improper Neutralization of Special Elements in Data Query Logic

GitHub_M

Related →
Contributing organizations · 1
GitHub_M

Assigning organization

2026-10-28

What changed

Follow changes
No substantive changes have been recorded here yet. History starts when cve.new observes a change after tracking is enabled; earlier edits are not reconstructed.

Large field values are marked as truncated previews. Original source snapshots remain retained.

References

4 sources