Failed second-factor codes are not counted toward account lockout

A failed password attempt counted toward an account lockout; a failed one-time code did not, on either sign in or re-authentication, and no rate limiting applied. An attacker holding a valid password could guess the second factor without limit.

Affected (1)

GPlatformgplatform-control
All versions affected.

Mitigations

Workarounds

Apply a rate limit in front of the sign in and re-authentication operations where infrastructure allows. This slows the attack but does not bind attempts to the account, so an attacker distributing requests across addresses is unaffected.
Monitor for repeated second-factor failures against a single account. A genuine user mistypes a code a handful of times, not thousands.
Where a password is believed to be compromised, reset it rather than relying on the second factor to hold.

Solutions

Update to a build in which a failed second-factor code counts toward the existing account lockout, on both sign in and re-authentication.
A request that asks to be prompted for a code, rather than submitting an incorrect one, is deliberately not counted, so normal use of a two-step client cannot cause a lockout.
Rate limiting remains worthwhile as defence in depth but is not the fix, because it bounds attempts per source rather than per account.

Exploits

With a known password, repeatedly submit candidate one-time codes. No attempt is recorded against the account and no lockout occurs.

Configurations

Exploitation requires a valid password for an existing account. It does not by itself defeat the password.
Affects both sign in and re-authentication for any account with a second factor enrolled.
Accounts that have not yet enrolled a second factor are not affected by this issue; their sessions are already restricted to enrolment.
The product applied no rate limiting to the affected operations, so no compensating control was present by default.

Overview

A failed password attempt counted toward an account lockout; a failed second-factor code did not. Neither sign in nor re-authentication recorded a failed one-time code, and the product applied no rate limiting to either operation.

An attacker in possession of a valid password could therefore guess the six-digit code without limit. Because verification accepts a small window of clock drift, a modest number of attempts reaches an even chance of success.

Re-authentication is the more significant of the two, as it governs the short elevated-privilege window required for sensitive operations.

Severity

CVSS v3

8.1 High

8.1

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack vector: Network
Attack complexity: High
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: High

Weaknesses (3)

Context

Impacts

Second-factor bypass at sign in. An attacker holding only a password can obtain a full session by guessing the one-time code. For a staff account this grants access to an administrative console able to change customer licensing and publish signed code.
CAPEC-112
Bypass of the elevated-privilege window. The same weakness in re-authentication allows an attacker to open the short window that governs key recovery, the minting of long-lived credentials, and a customer's approval of vendor staff access to their own tenancy.
CAPEC-49

Timeline

09/14/2026 00:00
Identified during an internal security review of GPlatform Control.
09/14/2026 00:30
Confirmed by analysis. No exploitation was performed against any running deployment, and there is no indication of exploitation in the wild.
09/14/2026 01:00
Reported to the vendor. Vendor and reporter are the same party, so no external coordination applies.
09/14/2026 02:00
Remediation began.
09/14/2026 04:40
Fixed in the product. A failed second-factor code now counts toward the existing account lockout on both sign in and re-authentication. Regression tests cover both operations and the deliberate exemption for a client requesting a prompt.