Someone already has your house key, and this bug lets them skip the alarm keypad on the way in
CVE-2026-13543 is a two-factor authentication bypass in Documenso, the open-source document signing platform (a DocuSign alternative). Versions 2.0 through 2.11.0 are affected. The flaw lives in packages/auth/server/lib/utils/handle-oauth-callback-url.ts: when a user authenticates via Google OAuth, the application grants a fully authenticated session *without enforcing the user's configured TOTP-based 2FA*. Email/password logins correctly prompt for the second factor; OAuth logins skip it entirely. The result is that any attacker who controls the victim's Google account — or can manipulate the OAuth callback — lands inside Documenso with no 2FA challenge. The fix PR (#2837) was closed without merging on August 30, 2026 due to inactivity, and no released version has patched this as of v2.19.0.
The vendor's MEDIUM 5.6 score is generous for what is effectively a second-layer bypass. The CVSS vector correctly marks AC:H (high complexity), but the scoring still overstates the real-world risk because it does not fully account for the *prerequisite chain*: an attacker must first compromise the victim's Google account or session before this bug even becomes relevant. At that point, the attacker already has access to the victim's email, Drive, and every other Google-integrated service — Documenso 2FA is a thin additional barrier, not the moat. For the small population of self-hosted Documenso instances where Google OAuth is enabled *and* users have opted into 2FA, this is a meaningful but narrow defense-in-depth failure, not a critical exposure.
4 steps from start to impact.
Compromise victim's Google account
- Victim uses Google OAuth to log in to Documenso
- Attacker obtains victim's Google credentials or active session
- Google accounts are protected by their own MFA, passkeys, and anomalous-login detection
- Google's Advanced Protection Program blocks most credential-theft scenarios
- Enterprise Google Workspace tenants enforce MFA and device trust
Initiate Documenso Google OAuth login
- Documenso instance has Google OAuth enabled (NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID set)
- Instance is network-reachable by attacker
- Self-hosted instances may not expose the login page to the internet
- Some deployments use OIDC/SAML via a different IdP, not Google directly
- Network-level access controls (VPN, IP allowlist) may gate the login page
2FA challenge is skipped
handle-oauth-callback-url.ts receives the OAuth callback and establishes a session. The code path does not check whether the resolved user has TOTP 2FA enabled — it creates the authenticated session immediately. The victim's 2FA configuration is silently bypassed.- Target user has 2FA enabled on their Documenso account
- Application version is 2.0–2.11.0 (unpatched)
- Only users who explicitly enabled 2FA are affected; users without 2FA see no behavioral difference
- Many Documenso deployments may not have 2FA enabled at all
Access victim's documents and signing workflows
- Successful session establishment from step 3
- Document-level access depends on what the victim had in their account
- Audit trail records all actions, creating post-compromise forensic evidence
NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID and related OAuth environment variables from your Documenso deployment. This eliminates the vulnerable code path completely. Users must authenticate via email/password, which correctly enforces 2FA. Since the noisgate verdict is LOW, there is no mitigation SLA — treat this as backlog hygiene. Apply when convenient, ideally before the next maintenance window./api/auth/callback/google endpoint) for anomalous access patterns.- Upgrading Documenso to the latest version (v2.19.0) — the fix PR #2837 was never merged, so all current versions remain vulnerable. Upgrading does not remediate this CVE.
- Enabling 2FA on more Documenso accounts — enabling 2FA actually *increases* the number of accounts susceptible to this bypass. The bug is that 2FA is skipped for OAuth logins, so adding 2FA to an account that uses Google OAuth creates a false sense of security.
- Web Application Firewall (WAF) rules — the OAuth callback is a legitimate application endpoint with a valid authorization code from Google. There is no malicious payload to signature-match; the bug is in the application's session logic after a successful OAuth handshake.
The supporting signals.
| In-the-wild exploitation | Not observed. Not listed in CISA KEV. No campaigns or threat actor reporting references this CVE. No GreyNoise or Shadowserver tags. |
|---|---|
| Proof of concept | Described as publicly available per VulDB. The GitHub issue #2758 by researcher APWine contains a detailed write-up of the bypass logic. No standalone weaponized PoC repo found on GitHub or pocindex.io. The fix PR #2837 inadvertently documents the exact code path. Exploitation is straightforward once the Google account prerequisite is met — it's just 'click Sign in with Google.' |
| EPSS score | 0.00586 (~0.6% probability of exploitation in next 30 days). Very low, consistent with a niche application and high-prerequisite attack. |
| KEV status | Not listed. No CISA KEV entry as of 2026-10-02. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L — Network-accessible, high complexity, no privileges or interaction required. Low across all CIA impacts. The AC:H correctly reflects the Google account compromise prerequisite. |
| Affected versions | Documenso v2.0.0 through v2.11.0 (45+ tagged releases). The CVE description caps at 2.11.0, but the fix was never merged — versions through v2.19.0 likely remain vulnerable. |
| Fix status | No patch available. PR #2837 was closed without merge on 2026-08-30 due to inactivity. No subsequent release (through v2.19.0) addresses the issue. |
| Scanning / exposure | Documenso is a niche self-hosted Node.js application. No Shodan/Censys/FOFA fingerprint data available. The SaaS instance at app.documenso.com is the largest single deployment. Self-hosted instances are estimated in the low hundreds based on ~15.3k GitHub stars and Docker adoption. |
| Disclosure timeline | Reported by APWine on 2026-05-02 via GitHub issue #2758. CVE published 2026-06-29. Fix PR opened and subsequently closed without merge by 2026-08-30. |
| Reporting researcher | APWine (GitHub user) — filed as a bug bounty report directly on the Documenso GitHub repository. |
Sources.
Why this verdict
- Google account prerequisite is a full prior compromise. The attacker must already control the victim's Google account (credentials or session). This is itself a HIGH-severity event that implies the attacker has access to Gmail, Drive, Calendar, and every Google-integrated service. The Documenso 2FA bypass adds marginal incremental risk on top of an already catastrophic position.
- Defense-in-depth failure, not primary auth bypass. This bug does not let an unauthenticated attacker into Documenso. It removes a *second layer* of protection that a subset of users opted into. The primary authentication (Google OAuth) still functions correctly — the identity verification happens at Google, not Documenso.
- Niche application with tiny attack surface. Documenso has ~15k GitHub stars and an estimated low-hundreds of self-hosted instances. The SaaS platform (app.documenso.com) is the largest deployment. This is not infrastructure-tier software; it's a line-of-business document signing tool.
- AC:H is earned and meaningful. The CVSS vector's High complexity accurately reflects that exploitation requires chaining a Google account compromise before the Documenso bypass is reachable. This is not a 'scan and exploit' vulnerability.
- Role multiplier: LOW. Documenso is a document signing application. It does not appear in the high-value-role catalog (not an IdP, domain controller, hypervisor, CI/CD pipeline, backup system, database engine, EDR agent, or network edge appliance). Its blast radius is confined to documents and signing workflows within the application — no lateral movement, no fleet compromise, no identity-tier escalation. Even in the worst case (enterprise legal team using Documenso for sensitive contracts), compromise is bounded to document exfiltration, not infrastructure control. No floor applies.
- No exploitation pressure. EPSS 0.6%, no KEV listing, no observed campaigns, no weaponized PoC tooling. The 'public exploit' is effectively the bug report itself describing 'log in with Google instead of password.'
Why not higher?
The vendor MEDIUM (5.6) overstates real-world risk because the CVSS formula does not adequately penalize the Google-account-compromise prerequisite. An attacker who already owns the victim's Google account gains relatively little additional leverage from bypassing Documenso's application-layer 2FA — they already have the victim's email, cloud storage, and every OAuth-integrated service. Documenso is not infrastructure; it processes documents, not credentials or fleet configuration. There is no realistic path from this bug to domain takeover, lateral movement, or supply-chain compromise.
Why not lower?
Despite the heavy prerequisites, this bug completely nullifies an explicit security control (TOTP 2FA) that security-conscious users intentionally enabled. For organizations that chose Documenso specifically for its self-hosted, auditable posture and layered authentication, losing 2FA without notice is a meaningful regression. The fact that no patch exists after four months of disclosure, and the fix PR was abandoned, means the exposure window is indefinite. IGNORE would undercount the risk for deployments that treat document signing as a compliance-sensitive workflow.
Crowdsourced verification payload.
Run this script on the host where Documenso is deployed (or against the Docker container). It checks the installed Documenso version from package.json and whether Google OAuth is configured. Requires read access to the application directory. Example: bash check_cve_2026_13543.sh /opt/documenso
#!/usr/bin/env bash
# CVE-2026-13543 - Documenso 2FA Bypass via Google OAuth
# Checks: (1) vulnerable version range, (2) Google OAuth enabled
# Usage: bash check_cve_2026_13543.sh <documenso_install_path>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -euo pipefail
INSTALL_PATH="${1:-}"
if [ -z "$INSTALL_PATH" ]; then
echo "Usage: $0 <documenso_install_path>"
echo " e.g. $0 /opt/documenso"
echo " For Docker: $0 /app (run inside container)"
exit 2
fi
PKG_JSON="$INSTALL_PATH/package.json"
ENV_FILE="$INSTALL_PATH/.env"
DOCKER_COMPOSE="$INSTALL_PATH/docker-compose.yml"
# --- Version check ---
if [ ! -f "$PKG_JSON" ]; then
echo "[UNKNOWN] Cannot find $PKG_JSON — verify path or run inside Docker container."
exit 2
fi
VERSION=$(grep -oP '"version"\s*:\s*"\K[^"]+' "$PKG_JSON" 2>/dev/null || true)
if [ -z "$VERSION" ]; then
echo "[UNKNOWN] Could not parse version from $PKG_JSON"
exit 2
fi
echo "Documenso version detected: $VERSION"
# Compare version — vulnerable range is 2.0.0 through 2.11.0
# But fix was never merged, so ALL 2.x versions are likely vulnerable
MAJOR=$(echo "$VERSION" | cut -d. -f1)
if [ "$MAJOR" -lt 2 ]; then
echo "[PATCHED] Version $VERSION is below the affected range (2.0.0+)."
exit 1
fi
# Since fix was never merged, all 2.x versions are vulnerable
# Check if the vulnerable file still has the unfixed code
VULN_FILE="$INSTALL_PATH/packages/auth/server/lib/utils/handle-oauth-callback-url.ts"
if [ -f "$VULN_FILE" ]; then
# Check if 2FA enforcement exists in the OAuth callback handler
if grep -qE '(verify.*2fa|check.*totp|twoFactor|two_factor)' "$VULN_FILE" 2>/dev/null; then
echo "[PATCHED] Found 2FA enforcement in OAuth callback handler."
exit 1
else
echo "[INFO] OAuth callback handler exists but lacks 2FA enforcement."
fi
fi
# --- Check if Google OAuth is configured ---
OAUTH_ENABLED="unknown"
if [ -f "$ENV_FILE" ]; then
if grep -qE 'NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID=.+' "$ENV_FILE" 2>/dev/null; then
OAUTH_ENABLED="yes"
else
OAUTH_ENABLED="no"
fi
elif [ -f "$DOCKER_COMPOSE" ]; then
if grep -qE 'NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID' "$DOCKER_COMPOSE" 2>/dev/null; then
OAUTH_ENABLED="yes"
else
OAUTH_ENABLED="no"
fi
fi
# Also check environment variables directly
if [ -n "${NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID:-}" ]; then
OAUTH_ENABLED="yes"
fi
echo "Google OAuth configured: $OAUTH_ENABLED"
if [ "$OAUTH_ENABLED" = "no" ]; then
echo "[PATCHED] Documenso $VERSION is in the vulnerable range, but Google OAuth is not configured. The vulnerable code path is unreachable."
exit 1
elif [ "$OAUTH_ENABLED" = "yes" ]; then
echo "[VULNERABLE] Documenso $VERSION with Google OAuth enabled is affected by CVE-2026-13543."
echo " Action: Disable Google OAuth or enforce MFA at the Google account level."
exit 0
else
echo "[VULNERABLE] Documenso $VERSION is in the affected range. Could not determine if Google OAuth is enabled — assume vulnerable."
echo " Action: Check if NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID is set. If so, disable it or enforce MFA at Google."
exit 0
fi