CVE-2026-61630: Time-Based One-Time Password (TOTP) Reuse/Replay in nginx-ignition

The nginx-ignition application provides an administrative panel to configure reverse proxies, SSL certificates, and access rules for the Nginx web server. Securing this interface is critical because access to this panel translates to broad administrative authority over the underlying system. To secure administrative access, nginx-ignition supports Multi-Factor Authentication (MFA) using Time-Based One-Time Passwords (TOTP).

In versions 2.33.0 through 2.35.0, the verification logic does not enforce single-use restrictions on TOTP codes. If an attacker intercepts or obtains a valid TOTP token along with the victim's primary credentials, they can authenticate successfully using the exact same code, provided the transmission occurs within the 30-second validity window of the token.

This vulnerability is classified under CWE-287 (Improper Authentication). The lack of stateful tracking of verified tokens exposes the administrative console to unauthorized access via credential replay, weakening the security guarantees of the multi-factor authentication mechanism.

The root cause of this vulnerability lies in the stateless nature of the application's TOTP verification logic. Standard TOTP implementations (as defined in RFC 6238) generate passwords based on a shared secret and the current Unix time step, typically lasting 30 seconds. To prevent replay attacks, the verifying server must maintain a state of previously accepted tokens and reject any token that has already been validated during its current time step.

Prior to version 2.35.1, nginx-ignition validated TOTP codes purely through mathematical verification using the Go library github.com/pquerna/otp. The library checks if the input matches the mathematical state expected for the secret key during the active temporal window.

Because the application failed to record whether a code had already been used, any mathematically correct token remained valid for multiple authentication attempts until the 30-second interval elapsed. If an administrative user successfully authenticated, an attacker who intercepted the transmitted token could immediately replay it to establish their own authenticated session.

The remediation introduced stateful tracking to record and verify previously used codes. In the user data model located at core/user/model.go, the application now maintains an array of recently processed TOTP tokens:

 type TOTP struct {
-	Secret    *string
-	Validated bool
+	Secret        *string
+	LastUsedCodes []string
+	Validated     bool
 }

In core/user/service.go, the login flow was updated to block subsequent authentications with the same token. The application executes TryUpdateLastUsedTOTPCode via the database repository after mathematical validation passes. If the code has been used before, authentication is rejected:

		if !totp.Validate(code, *totpData.Secret) {
			return AuthenticationFailed, nil, nil
		}
+
+		updated, err := s.repository.TryUpdateLastUsedTOTPCode(ctx, usr.ID, code)
+		if err != nil || !updated {
+			return AuthenticationFailed, nil, err
+		}
+
+		usr.TOTP.LastUsedCodes = append([]string{code}, usr.TOTP.LastUsedCodes...)
+		if len(usr.TOTP.LastUsedCodes) > 3 {
+			usr.TOTP.LastUsedCodes = usr.TOTP.LastUsedCodes[:3]
+		}

To ensure thread safety and avoid race conditions, the validation relies on database-level checks. In database/user/repository.go, an atomic query ensures that duplicate codes are ignored by using explicit database updates:

+func (r *repository) TryUpdateLastUsedTOTPCode(ctx context.Context, id uuid.UUID, code string) (bool, error) {
+	result, err := r.database.Update().
+		Model((*userModel)(nil)).
+		Set("totp_last_used_codes = SUBSTR(? || COALESCE(',' || totp_last_used_codes, ''), 1, 20)", code).
+		Where("id = ? AND (totp_last_used_codes IS NULL OR (',' || totp_last_used_codes || ',') NOT LIKE ?)", id, "%,"+code+",%").
+		Exec(ctx)
...

If the SQL query modifies zero rows due to the conditional checks in the Where statement, the repository returns false, causing the authentication workflow to abort.

To exploit this vulnerability, an attacker must first possess the victim's primary login credentials (username and password). Once credentials are acquired, the attack requires interception of the user's login sequence, which can occur on unencrypted networks or via administrative logging.

An attacker position on a local area network or a shared proxy allows sniffing of the unencrypted JSON payload directed to /api/users/login. The payload exposes the standard username, password, and active 6-digit TOTP string.

By programmatically executing an HTTP POST request containing the captured credentials and the identical TOTP string within the active 30-second time-step, the server's stateless logic authorizes the second request. The endpoint responds with a unique, valid administrative JSON Web Token (JWT) for the attacker's session, granting immediate access to the administrative dashboard.

Successful exploitation of this flaw completely neutralizes the security benefits of Multi-Factor Authentication. The vulnerability yields administrative privileges to the nginx-ignition dashboard, allowing adversaries to modify active Nginx server blocks, alter SSL parameters, write unauthorized redirection rules, and modify administrative user settings.

Although the CVSS v3.1 score is calculated as 4.2 (Medium), the real-world operational threat is elevated. The CVSS metric designates a high complexity (AC:H) because the exploit requires sniffing the network traffic or acquiring the token stream dynamically during user sign-on, alongside needing primary credentials (PR:H).

If an organization hosts nginx-ignition on unencrypted HTTP channels within corporate local networks, the risk increases exponentially. The vulnerability allows rapid escalation of access from basic credential theft to complete network configuration control.

The recommended remediation is upgrading the nginx-ignition deployment directly to version v2.35.1 or higher. The patch fully mitigates the reuse vector by transitioning token verification from a purely mathematical calculation to a stateful database constraint.

The implemented fix is complete for standard operational deployments. By tracking the three most recently validated codes, the database check safely covers the default 30-second time window as well as common clock drift adjustments. Because the database operation is atomic, race conditions are blocked, preventing multiple login endpoints from parallel processing the same token.