cPanel 134.0.34 2FA Loop When Accessing cPanel Accounts from WHM: Known Bug CPANEL-53684 and How to Fix It

If you administer a cPanel server and recently updated to version 11.134.0.34, you may have noticed a strange behavior: when you (as root or as a reseller) try to access a customer's cPanel account directly from your WHM session, you are unexpectedly prompted for your own WHM user's two-factor authentication code. Worse, entering a valid 2FA code does not complete the login. The prompt simply loops, asking for another code, then another, with no error message and no path forward. This article explains why this happens, the official cPanel fix, and what to do if you cannot apply the fix immediately.

The symptom in detail

The bug manifests in a specific workflow that is common for hosting administrators and resellers: logging into WHM as root or as a reseller user, navigating to a cPanel account in the list, and clicking the option to access that account's cPanel interface. On affected versions, this workflow no longer takes you to the user's cPanel home page. Instead, it shows the WHM user's 2FA prompt (the one for the WHM session, not the cPanel user's own 2FA), and any code you enter is rejected by being asked for again.

The bug is not a credential issue. The 2FA codes you enter are correct. The bug is in the cPanel session handling logic introduced in 11.134.0.34 that incorrectly evaluates the 2FA verification state when transitioning from a WHM session to a cPanel user session. The verification succeeds technically but the session state machine does not advance to the next step, so it re-prompts for verification indefinitely.

This bug does not affect direct cPanel logins (where the customer logs into their own cPanel from the public-facing login page). It only affects the WHM-to-cPanel transition path that root and reseller users rely on for support work.

The official cPanel reference

cPanel confirmed this as a real bug under internal developer case CPANEL-53684. The official cPanel support article documents the behavior and the fix path. The bug was introduced in 11.134.0.34 and fixed in 11.134.0.35. cPanel also shipped equivalent fixed builds across the supported branches that were affected, so the resolution is available regardless of which release tier your server runs on.

If your hosting provider or you can confirm the cPanel build version on your server, that determines whether you are affected and what the fix path is.

How to check your cPanel build version

As root on the affected server:

/usr/local/cpanel/cpanel -V

This returns a string like 11.134.0.34 or 11.134.0.35 or similar. If you see 11.134.0.34, you are running the affected build. If you see 11.134.0.35 or later, you should already have the fix. If you see a build from a different branch (11.110, 11.126, 11.136), check whether your specific build is the fixed version for that branch.

The fix

cPanel published fixed builds for every affected branch. The recommended fix path depends on which release tier your server runs on:

• 11.134 branch: update to 11.134.0.35 or later
• 11.136 branch: cPanel shipped a corresponding fixed build, check cPanel's CPANEL-53684 advisory page for the exact build number
• 11.126 branch: cPanel shipped a corresponding fixed build, check the advisory page for the exact build number
• 11.110 ELS branch: a fixed build is available for this Extended Lifecycle Support branch

The update procedure is the standard cPanel update flow. As root:

/scripts/upcp --force

The --force flag forces an immediate update through cPanel's normal upgrade flow, ignoring any scheduled delay. After the update completes, verify the new build version with /usr/local/cpanel/cpanel -V and confirm it matches the fixed build for your branch.

Restart cpsrvd after the update to make sure the corrected session handling code is loaded:

/scripts/restartsrv_cpsrvd

Then test the WHM-to-cPanel workflow that was failing. The 2FA loop should be resolved.

Workarounds if you cannot upgrade immediately

If you cannot update right now (change-control reasons, maintenance window not available, customer-impact concerns about the update itself), here are the available workarounds. None of them are great, and all of them have tradeoffs:

Workaround 1: temporarily disable 2FA on the WHM user account

This is the most reliable workaround for getting WHM-to-cPanel access working again, but it disables a meaningful security control for the duration. In WHM, navigate to Account Information, then Two-Factor Authentication, and disable 2FA for your WHM user. The WHM-to-cPanel transition will then work normally because the buggy 2FA verification step is no longer in the path.

Re-enable 2FA immediately after you upgrade to a fixed build. If you operate with multiple WHM users (multiple admins or resellers), you can disable 2FA for just the users who need to perform WHM-to-cPanel transitions while keeping it enabled for others.

Workaround 2: use direct cPanel login instead

Rather than transitioning from WHM to cPanel, log directly into the customer's cPanel account using their cPanel credentials at the customer-facing cPanel URL. This bypasses the WHM-to-cPanel transition entirely, so the bug does not trigger.

The practical issue is that this requires you to have the customer's cPanel password, which is a security and operational tradeoff (you should not normally know customer cPanel passwords, and resetting passwords every time you need access is intrusive for the customer). Use the cPanel password reset flow only when necessary, communicate clearly with the customer, and rotate the password after the work is done.

Workaround 3: use API access for the operation you need

If the reason you were transitioning to a customer's cPanel was to perform a specific administrative action (modify a setting, install something, run a script), check whether WHM API 1 or UAPI can do the same operation from a root session. Many things you would normally do via the cPanel UI have direct API equivalents that do not trigger the 2FA bug.

Examples: changing email passwords, listing databases, modifying DNS records, managing SSL certificates. All have UAPI endpoints that root can call directly without entering the customer's cPanel UI.

What does not work

For completeness, a few approaches that look like they might work but do not:

• Clearing browser cookies and logging in again: the bug is server-side, not client-side. Fresh sessions encounter the same loop.
• Trying a different browser: same reason. Server-side bug.
• Logging out of WHM and back in: does not help, because the bug triggers on the transition itself.
• Disabling cPanel user 2FA: the loop is on the WHM user's 2FA, not the cPanel user's. Disabling cPanel-side 2FA does nothing.

Why this matters operationally

The 2FA loop bug is functionally a denial-of-service against hosting administrators and resellers. It does not compromise security or expose data, but it blocks a workflow that hosting providers use constantly: jumping into a customer's cPanel from WHM to diagnose an issue, make a change, or verify a configuration. On a busy hosting provider, this workflow may happen dozens of times per day.

The bug is more disruptive than it sounds because the natural reaction to a 2FA loop is to assume something is wrong with the user's 2FA setup, which leads administrators down debugging paths that do not surface the actual cause. The fact that cPanel assigned a developer case (CPANEL-53684) and shipped fixed builds across multiple branches in short order suggests they understood the operational impact.

For Gotekky customers, this is a non-issue: managed servers run on patched builds, and the fix was applied during the normal post-release verification process. If you operate self-managed cPanel infrastructure, get to a fixed build as soon as you have a maintenance window, and use the workarounds above sparingly in the meantime.

Related upgrade notes

The 11.134.0.35 release that fixed CPANEL-53684 was a routine maintenance release without other significant security fixes. The major cPanel security releases in spring 2026 are documented in separate Gotekky guides, including the April 28 CVE-2026-41940 authentication bypass, the May 13 patch covering five additional CVEs, the May 19 emergency for SEC-73728, SEC-73755, and the actively-exploited LiteSpeed plugin issue, and the follow-up June 2 LiteSpeed plugin advisory. If you are catching up on multiple cPanel updates after a period of pause, review each guide to understand what each release covers before deploying.