CVE-2026-32730: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32730 is an MFA/TOTP bypass vulnerability in ApostropheCMS caused by an incorrect MongoDB query in the bearer token authentication middleware. The flaw allows incomplete login tokens — where password verification succeeded but TOTP/MFA was not completed — to be accepted as fully authenticated bearer tokens, completely negating multi-factor authentication protections. It affects all ApostropheCMS versions from 3.0.0 through 4.27.1 (npm package apostrophe) when used with @apostrophecms/login-totp or any custom afterPasswordVerified login requirement. Disclosed on March 18, 2026, it carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, ApostropheCMS Advisory).

The root cause is a logic error (CWE-287: Improper Authentication; CWE-305: Authentication Bypass by Primary Weakness) in the getBearer() function within @apostrophecms/express/index.js at lines 386–389. The MongoDB query uses { requirementsToVerify: { $ne: [] } } intending to match tokens where all MFA requirements are satisfied (empty array), but $ne: [] actually matches any non-empty array — meaning tokens with pending TOTP requirements are incorrectly accepted. The correct operator should be { requirementsToVerify: { $size: 0 } }. A secondary amplifying bug in @apostrophecms/login/index.js (lines 728–729, 735–736) causes finalizeIncompleteLogin to attempt token deletion using token.userId instead of token._id, so the incomplete token is never removed from the database and remains exploitable for its full lifetime (default: 1 hour). A public PoC script (mfa-bypass-poc.js) demonstrating the query logic bug is included in the security advisory (ApostropheCMS Advisory).

Successful exploitation grants an attacker complete, fully authenticated API access to the ApostropheCMS instance as the targeted user — including administrative accounts — without ever supplying a valid TOTP code. This results in high confidentiality, integrity, and availability impact: attackers can read, modify, or delete all CMS content and data, manage users, and potentially upload malicious content or web shells. The bypass is particularly severe because MFA is specifically designed to protect accounts when passwords are compromised (e.g., via credential stuffing or phishing), and this vulnerability nullifies that protection entirely (ApostropheCMS Advisory).

A public proof-of-concept (mfa-bypass-poc.js) is available within the official security advisory, demonstrating the MongoDB query logic bug across all token states using a runnable Node.js script (ApostropheCMS Advisory). There is no evidence of active in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.055% (0.13% per GitHub Advisory), placing it in the 32nd percentile for exploitation probability within 30 days. The vulnerability is not currently listed in the CISA KEV catalog. Exploitation requires the attacker to already possess the victim's valid password, which raises the attack complexity but is a realistic precondition given widespread credential exposure (GitHub Advisory).

1. Reconnaissance: Identify ApostropheCMS deployments (versions ≤ 4.27.1) with MFA/TOTP enabled (@apostrophecms/login-totp). This can be done via Shodan, Censys, or by inspecting login page behavior for TOTP prompts.
2. Obtain victim credentials: Acquire the target user's username and password through credential stuffing, phishing, or a database breach. The attacker does NOT need the TOTP secret or code.
3. Initiate login to obtain incomplete token: Send a password-only login request to the API endpoint:

POST /api/v1/@apostrophecms/login/login
Content-Type: application/json
{"username": "admin", "password": "correct_password", "session": false}

4. Capture the incomplete token: The server verifies the password, requires TOTP, and returns an incompleteToken in the response:

{"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}

5. Use incomplete token as a bearer token: Submit the incompleteToken directly as an Authorization: Bearer header to any authenticated API endpoint:

GET /api/v1/@apostrophecms/page
Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx

6. Achieve full authenticated access: The vulnerable getBearer() middleware matches the token because requirementsToVerify: ["AposTotp"] satisfies $ne: []. The attacker is granted full API access as the victim (req.user is set, req.csrfExempt = true) without ever providing a TOTP code. Due to the secondary token deletion bug, the incomplete token persists for up to 1 hour even after the legitimate user completes MFA (ApostropheCMS Advisory).

• Network: Unexpected API requests using Authorization: Bearer <cuid> headers to authenticated endpoints (e.g., /api/v1/@apostrophecms/page) shortly after a login attempt that returned an incompleteToken response; API calls from an IP address that did not complete the TOTP verification step.
• Logs: ApostropheCMS access logs showing a POST /api/v1/@apostrophecms/login/login request (returning incompleteToken) followed immediately by authenticated API requests from the same IP without a corresponding TOTP verification request (/api/v1/@apostrophecms/login/totp or equivalent); repeated bearer token usage from unusual geographic locations or IP addresses.
• Database: Presence of bearer token documents in MongoDB (apostrophe-login-bearer-tokens collection or equivalent) with a non-empty requirementsToVerify array that have been accessed or matched by queries; incomplete tokens that were never deleted despite the user completing MFA login.
• Application Behavior: Authenticated CMS actions (content edits, user management, file uploads) occurring without a corresponding completed MFA session in audit logs (ApostropheCMS Advisory).

Upgrade ApostropheCMS to version 4.28.0 or later, which corrects both the MongoDB query bug ($ne: [] → $size: 0) and the token deletion bug (token.userId → token._id) (ApostropheCMS Advisory, GitHub Advisory). If immediate patching is not possible, consider disabling bearer token authentication or restricting API access via network-level controls (firewall rules, VPN requirements) until the patch can be applied. After patching, review access logs for suspicious bearer token usage patterns and manually purge any lingering incomplete tokens from the database. Organizations should also rotate credentials for any accounts that may have been targeted.

The vulnerability was reported by security researcher 0xkakash1 and published by the ApostropheCMS maintainer (BoDonkey) on March 18, 2026 via GitHub Security Advisory (ApostropheCMS Advisory). The advisory received coverage from automated vulnerability tracking services including ENISA's EUVD, CIRCL, and CVEFeed shortly after disclosure. A Mastodon post from @thehackerwire noted the vulnerability on the day of disclosure. Red Hat also tracked the CVE as of late March 2026. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified.