WHM 2FA rejects valid TOTP codes across 40 servers — 11.136.0.35

Subject: WHM 2FA rejects valid TOTP codes across 40 servers — 11.136.0.35

Hello,

Starting on 25 August 2026 (afternoon, +03), WHM two-factor authentication began rejecting valid TOTP codes across approximately 40 of our servers simultaneously. All servers run cPanel & WHM 11.136.0.35 on CloudLinux 8. No configuration changes were made on our side.

SYMPTOM

At the WHM login screen, the password is accepted and the 2FA prompt appears. Entering a valid code either returns to the login screen with no error message, or returns "The security code is invalid." The account is never logged in.

WHAT WE HAVE VERIFIED

1. The TOTP secret is correct. We extracted the root secret from /var/cpanel/authn/twofactor_auth/tfa_userdata.json and generated a code with:
     oathtool --totp -b '<REDACTED>'
   The generated code matches the code shown by our authenticator app exactly. WHM still rejects it.

2. System time is correct and synchronised. timedatectl reports "System clock synchronized: yes" and "NTP service: active" with an active chronyd.

3. SSH 2FA using the same secret works. pam_google_authenticator accepts the same codes without issue (confirmed in /var/log/secure).

4. API-generated sessions work. "whmapi1 create_user_session user=root service=whostmgrd" produces a URL that logs in successfully. This path bypasses TOTP verification, which isolates the failure to the 2FA verification step rather than to session handling, cookies, or the network path.

5. Session creation itself is healthy. A direct login POST returns status 1 with a valid security_token and a whostmgrsession cookie, and the resulting cpsess URL returns HTTP 200.

6. Not a proxy or network issue. Requests reach the server and appear in the logs; the failure reproduces from the server's own loopback and public IP via curl.

ADDITIONAL OBSERVATIONS

A. Frozen log timestamps. Every entry written to /usr/local/cpanel/logs/access_log and session_log carries the timestamp 2026-08-24 14:41:53, including entries written today, while the system clock reads the correct current time and cpsrvd processes were started today. Example:

     # date
     Tue Aug 25 16:15:30 +03 2026
     # tail -1 /usr/local/cpanel/logs/session_log
     [2026-08-24 14:41:53 +0300] info [whostmgrd] <IP-REDACTED> NEW root:<SESSION-REDACTED> address=<IP-REDACTED>,app=whostmgrd,creator=root,method=handle_form_login,path=form,possessed=0

   Sessions created minutes earlier appear under this stale timestamp. Since TOTP validation is time-based, we suspect this frozen time value and the 2FA failure may share a root cause inside cpsrvd.

B. Malformed redirect. Before running "upcp --sync --force" on one server, the login POST returned:

     {"status":1,"security_token":"/cpsess<REDACTED>","redirect":"/cpsess<REDACTED>/?=undefined&login=1&post_login=<REDACTED>"}

   Note the "?=undefined" parameter. After "upcp --sync --force" the redirect returned clean, but 2FA still fails.

C. Behaviour changed after a package downgrade. Downgrading alt-pcre2 from 10.47-1.el8 to 10.34-1.el8 changed the failure from a silent redirect loop to an explicit "The security code is invalid." message. We have since restored 10.47.

D. Overnight package transaction. An automatic dnf update ran at 04:25 on 25 August on all affected servers: stunnel 5.71-2.el8_10 installed; MariaDB 10.11.18 to 10.11.19; NetworkManager 1.40.16-20 to -21; and alt-pcre2 10.34-1.el8 to 10.47-1.el8. The alt-pcre2 jump is the largest version change in the set.

WORKAROUND IN USE

Rewriting the 2FA record restores access — removing the user config, or resetting tfa_userdata.json to {} and re-enrolling, both work. Re-entering the same original secret afterwards also works, which indicates the stored value is not itself corrupt.

We are currently running with 2FA disabled server-wide (whmapi1 twofactorauth_disable_policy) and WHM ports restricted by IP, which is not an acceptable long-term posture for us.

WHAT WE NEED

Please confirm whether this is a known regression in 11.136.0.35, whether 11.136.0.36 addresses it, and whether other customers have reported the same. We can provide full unredacted logs or remote access on a test server through a secure channel on request.

Thank you,