WHMCS 9.0.4: cPanel/WHM SSO fails for Google Sign-In client owner until local password is set

[MarceloPe]

Hi everyone,

I searched the community first but could not find an exact match for this behavior. I’m trying to determine whether this is expected behavior, a security hardening change, or a possible regression/bug in WHMCS 9.0.4.

Environment:
- WHMCS version: 9.0.4
- Upgrade path: 9.0.3 to 9.0.4 using the official incremental patch
- PHP version: 8.3
- ionCube Loader: 14.4.x
- Server module: cPanel/WHM
- Client login method involved: Google Sign-In
- cPanel/WHM Single Sign-On enabled

Issue:
After updating to WHMCS 9.0.4, a client reported that the “Login to WHM” / “Login to cPanel” action from the Client Area failed with:
 

Action Failed
Unable to auto-login. Please contact support.

Reproduction details:
1. Client logs in to the WHMCS Client Area using Google Sign-In.
2. Client opens the product/service details page for an active cPanel/WHM hosting service.
3. Client clicks the “Login to WHM” or “Login to cPanel” button.
4. WHMCS shows the error above.

Expected result:
The client should be logged in to WHM/cPanel via SSO.

Actual result:
The SSO action fails with “Unable to auto-login”.

Important details:
- This issue appeared to affect only this specific client/user. Other clients with cPanel/WHM services were able to use Client Area SSO normally after the 9.0.4 update.
- The affected user was the account owner.
- The client account had SSO enabled.
- In the database, tblclients.allow_sso = 1.
- In tblusers_clients, the affected user had owner = 1 and permissions = NULL, which I understand is normal for the account owner.
- Admin-side access/SSO worked.
- “Login as Client” from the WHMCS admin area worked.
- cPanel API connectivity itself did not appear to be broken.
- Other checks did not point to Cloudflare, ModSecurity, tmp path, cPanel API token, or server connectivity.

What resolved it:
The client usually logged in using Google Sign-In and apparently did not have a local WHMCS password set from the Client Area.

After asking the client to define a local WHMCS password, the cPanel/WHM SSO action immediately started working.

After that, SSO worked in both scenarios:
- when logging in with email + password
- when logging in again using Google Sign-In

So the local password only had to be set once. After that, Google Sign-In also allowed the cPanel/WHM SSO action to work.

Additional checks:
- I checked for NULL or empty tblusers.password values and did not find any.
- All password fields I checked had bcrypt-style $2y$ prefixes, so checking for NULL/empty passwords does not seem to identify this condition.
- I also found a few unrelated clients with allow_sso = 0 and corrected those, but this affected client already had allow_sso = 1.

Questions:
1. Is WHMCS 9.0.4 expected to require the account owner to have a local password set before allowing Client Area SSO actions such as cPanel/WHM login?
2. Could this behavior be related to the 9.0.4 Client Area authorization/security hardening?
3. Is this intended behavior, or should it be reported as a bug/regression?
4. Is there a reliable way to identify users who authenticate via Google Sign-In but may not have completed local password setup, if tblusers.password is not NULL/empty?

I’m not looking for details about the security issue itself. I’m only trying to confirm whether this new behavior is intentional and how to detect or prevent it for other clients.

Thanks.

Edited 20 hours ago by MarceloPe