CVE-2026-32729: Runtipi Auth Bypass Vulnerability

CVE-2026-32729 Overview

CVE-2026-32729 is a critical authentication bypass vulnerability in Runtipi, a personal homeserver orchestrator. The vulnerability exists in the /api/auth/verify-totp endpoint, which fails to enforce rate limiting, attempt counting, or account lockout mechanisms. This security flaw allows attackers who have obtained a user's valid credentials to brute-force the 6-digit TOTP code and completely bypass two-factor authentication protection.

Critical Impact

An attacker with compromised credentials can bypass two-factor authentication by brute-forcing all 1,000,000 possible TOTP codes within approximately 33 minutes, gaining full unauthorized access to user accounts.

Affected Products

• Runtipi versions prior to 4.8.1
• Runtipi homeserver installations with TOTP two-factor authentication enabled
• Self-hosted Runtipi instances accessible over the network

Discovery Timeline

• 2026-03-16 - CVE CVE-2026-32729 published to NVD
• 2026-03-17 - Last updated in NVD database

Technical Details for CVE-2026-32729

Vulnerability Analysis

This vulnerability represents a classic improper restriction of excessive authentication attempts (CWE-307). The Runtipi application's TOTP verification endpoint lacks fundamental security controls that are essential for protecting authentication mechanisms. Without rate limiting or lockout mechanisms, the endpoint becomes susceptible to automated brute-force attacks.

The TOTP verification session persists for 24 hours based on the default cache TTL configuration. This extended window provides attackers with ample time to systematically enumerate the entire keyspace of possible TOTP codes. Given that TOTP codes are 6-digit numeric values (ranging from 000000 to 999999), there are exactly 1,000,000 possible combinations to test.

Root Cause

The root cause of this vulnerability is the absence of security controls on the /api/auth/verify-totp endpoint. Specifically, the endpoint lacks:

1. Rate limiting - No throttling mechanism exists to slow down repeated verification attempts
2. Attempt counting - The system does not track failed verification attempts per user or session
3. Account lockout - No temporary or permanent lockout is triggered after multiple failed attempts
4. Session invalidation - The TOTP verification session remains valid for an excessive 24-hour period

These missing controls combine to create a scenario where automated attacks can proceed unimpeded.

Attack Vector

The attack requires network access and assumes the attacker has already obtained valid user credentials through methods such as phishing, credential stuffing, or data breaches. Once credentials are obtained, the attacker targets the TOTP verification step.

The attack proceeds as follows:

1. The attacker obtains valid credentials for a target account
2. The attacker initiates a login attempt, triggering the TOTP verification step
3. Automated tools send requests to /api/auth/verify-totp cycling through all possible 6-digit codes
4. At approximately 500 requests per second, the entire keyspace of 1,000,000 codes can be exhausted in roughly 33 minutes
5. Once the correct code is submitted, the attacker gains full access to the account, bypassing 2FA entirely

The exploitation mechanism involves iterating through TOTP codes from 000000 to 999999 against the unprotected verification endpoint. Due to the lack of rate limiting, an attacker can submit hundreds of verification requests per second until the correct code is found. For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-32729

Indicators of Compromise

• Unusually high volume of requests to /api/auth/verify-totp from a single IP address or session
• Sequential or near-sequential TOTP code submissions indicating automated enumeration
• Successful authentication following a large number of failed TOTP verification attempts
• Authentication events from geographic locations inconsistent with legitimate user patterns

Detection Strategies

• Implement monitoring for high-frequency requests to the TOTP verification endpoint (threshold: >10 requests per minute per session)
• Alert on authentication anomalies where successful login follows multiple failed TOTP attempts
• Correlate login attempts with known credential breach databases to identify at-risk accounts
• Monitor for automated tool signatures in User-Agent strings and request patterns

Monitoring Recommendations

• Enable verbose logging on authentication endpoints to capture all TOTP verification attempts
• Configure real-time alerting for brute-force attack patterns against authentication services
• Implement network-level monitoring to detect high-volume request bursts to the Runtipi API
• Review authentication logs regularly for signs of credential abuse or 2FA bypass attempts

How to Mitigate CVE-2026-32729

Immediate Actions Required

• Upgrade Runtipi to version 4.8.1 or later immediately to address this vulnerability
• Audit authentication logs for signs of historical exploitation attempts
• Force password resets for any accounts showing suspicious TOTP verification patterns
• Consider temporarily disabling external network access to Runtipi instances until patched

Patch Information

The vulnerability has been fixed in Runtipi version 4.8.1. The patch implements proper rate limiting and security controls on the TOTP verification endpoint. Users should update their Runtipi installations immediately by following the standard upgrade procedure. Full details are available in the GitHub Security Advisory (GHSA-v6gf-frxm-567w).

Workarounds

• Place a reverse proxy (such as Nginx or Caddy) in front of Runtipi with rate limiting configured for the /api/auth/verify-totp endpoint
• Implement IP-based access controls to restrict Runtipi access to trusted networks only
• Deploy a Web Application Firewall (WAF) with brute-force detection capabilities
• Reduce the TOTP session cache TTL from the default 24 hours to minimize the attack window

# Example Nginx rate limiting configuration for Runtipi
# Add to your Nginx server configuration

# Define rate limiting zone (10 requests per minute per IP)
limit_req_zone $binary_remote_addr zone=totp_limit:10m rate=10r/m;

# Apply rate limiting to TOTP endpoint
location /api/auth/verify-totp {
    limit_req zone=totp_limit burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://runtipi_backend;
}