← Back to Feed CACHED · 2026-10-01 18:58:46 · CACHE_KEY CVE-2026-13543
CVE-2026-13543 · CWE-287 · Disclosed 2026-06-29

Documenso Google OAuth Login 2FA Bypass via handle-oauth-callback-url.ts

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"2FA bypass requires prior Google account compromise — defense-in-depth gap, not a front door"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Compromise victim's Google account

The attacker obtains the victim's Google credentials or an active Google session — via phishing, credential stuffing, session hijack, or infostealer malware. Without this, the OAuth flow cannot be initiated on behalf of the target user. This is the hard prerequisite that gates the entire chain.
Conditions required:
  • Victim uses Google OAuth to log in to Documenso
  • Attacker obtains victim's Google credentials or active session
Where this breaks in practice:
  • 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
Detection/coverage: Google Workspace login alerts; impossible-travel detections in IdP logs; SIEM correlation of new OAuth grants
STEP 02

Initiate Documenso Google OAuth login

The attacker navigates to the target Documenso instance and selects 'Sign in with Google.' Because they control the Google session, Google's OAuth consent screen is satisfied, and an authorization code is returned to Documenso's callback endpoint.
Conditions required:
  • Documenso instance has Google OAuth enabled (NEXT_PUBLIC_WEBAPP_AUTH_GOOGLE_CLIENT_ID set)
  • Instance is network-reachable by attacker
Where this breaks in practice:
  • 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
Detection/coverage: Documenso access logs showing OAuth callback requests; WAF logs
STEP 03

2FA challenge is skipped

Documenso's 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.
Conditions required:
  • Target user has 2FA enabled on their Documenso account
  • Application version is 2.0–2.11.0 (unpatched)
Where this breaks in practice:
  • 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
Detection/coverage: No specific detection for the skip itself; correlate OAuth login events for 2FA-enrolled users who did not complete a TOTP challenge
STEP 04

Access victim's documents and signing workflows

With a valid Documenso session, the attacker can view, download, and sign documents on behalf of the victim. They can access pending signing requests, completed documents, templates, and API keys. In an enterprise context, this could expose contracts, NDAs, and other legally sensitive materials.
Conditions required:
  • Successful session establishment from step 3
Where this breaks in practice:
  • Document-level access depends on what the victim had in their account
  • Audit trail records all actions, creating post-compromise forensic evidence
Detection/coverage: Documenso audit logs showing document access, signature events, or API key usage from an unexpected IP/device
03 · Compensating Control

1
LOW 3.5→IGNORE 0.0
SEVERITY REDUCED
Disable Google OAuth login entirely — Remove or unset the 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.
2
LOW 3.5→LOW 2.5
Enforce MFA at the Google Workspace / IdP level — If disabling Google OAuth is not feasible, ensure all users who access Documenso via Google OAuth have strong MFA enforced at the Google account level (FIDO2/passkey preferred). This hardens the prerequisite step — if the attacker cannot compromise the Google account, the Documenso 2FA bypass is unreachable. Configure Google Workspace to require phishing-resistant MFA for all users in the Documenso user group.
3
LOW 3.5→LOW 3.0
Monitor OAuth login events for 2FA-enrolled users — Add a detection rule in your SIEM or Documenso audit log pipeline: alert when a user who has 2FA enabled completes an OAuth-based login without a corresponding TOTP verification event. This won't prevent exploitation but provides immediate visibility if the bypass is exercised. Review Documenso's application logs (/api/auth/callback/google endpoint) for anomalous access patterns.
4
LOW 3.5→IGNORE 1.0
SEVERITY REDUCED
Restrict network access to Documenso login page — Place the Documenso instance behind a VPN, reverse proxy with IP allowlisting, or zero-trust access gateway (e.g., Cloudflare Access, Tailscale). This prevents external attackers from reaching the OAuth login flow even if they have the victim's Google credentials. Reduces the attack surface to internal-only or managed-device-only access.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot observed. Not listed in CISA KEV. No campaigns or threat actor reporting references this CVE. No GreyNoise or Shadowserver tags.
Proof of conceptDescribed 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 score0.00586 (~0.6% probability of exploitation in next 30 days). Very low, consistent with a niche application and high-prerequisite attack.
KEV statusNot listed. No CISA KEV entry as of 2026-10-02.
CVSS vectorCVSS: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 versionsDocumenso 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 statusNo 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 / exposureDocumenso 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 timelineReported 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 researcherAPWine (GitHub user) — filed as a bug bounty report directly on the Documenso GitHub repository.

Sources.

  1. OpenCVE – CVE-2026-13543
  2. OSV – CVE-2026-13543
  3. GitHub Issue #2758 – 2FA Bypass via Google OAuth
  4. GitHub PR #2837 – Fix attempt (closed, never merged)
  5. Documenso GitHub Repository
  6. Documenso Releases
  7. Hol.org – CVE-2026-13543 Advisory
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (3.5/10)

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.

06 · Verification

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

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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