Unable to logon to user's accounts after update to 136.0.20
I just updated to 136.0.20.
I cannot log in like I used to, from my root WHM account to any cpanel user account.
I get "Invalid Username". I still can login to those accounts through their own user and password.
Last week you changed this so we had to enter again the 2FA (and it was ok), but this is not good, please help
-
I'm having same issue today
0 -
If anyone else is getting this problem, I could bypass it by using my main domain for the server (server1.xxxxx) instead of some other domain I used to use. Maybe was some cache (I did tried erasing it), but now I can use this feature again, so that's good.
0 -
Same thing here, for both v136.0.20 and v110.0.127. The cPanel icon in the accounts list no longer logs into their cPanel. Instead, you get a password page that says "The login is invalid" with the user's username populating the first field.
0 -
And now, after logging out of WHM in v136.0.20 I cannot log back in using the correct credentials. Ugh. This needs to be fixed as soon as possible! I am DOA at the moment.
0 -
I am seeing the same issue when trying to access any account on my server. "The login is invalid" Username box populated with that account username. I can't get into any accounts. Has anyone found a workaround?
0 -
Updated to 136.0.20 this morning.
0 -
Ok so here is a workaround. In terminal:
whmapi1 create_user_session user=<username> service=cpaneld | grep url
That will start a session and return a url you can use in the browser to get into the cPanel for that user. No SSL but at least you can get in.
0 -
136.0.20 - It doesn't work as it should. We need new path!
0 -
I had this issue when updated, i solved it loging out from whm and login in again at all my servers… try also in incognito window.
2 -
Just checked and I am back to normal after logging out, clearing the browser cache, and logging back in. Thanks Eduardo.
Still have to enter my 2FA code every time I open an account cPanel but I'm almost used to it now. Grrr
1 -
Glad to hear that helped, Michael.
Regarding the 2FA prompt when accessing cPanel accounts from WHM, that's actually expected behavior since a recent security change. It can be a bit annoying at first, but it adds an extra layer of protection by requiring re-authentication before accessing a user's account.
0 -
All of my servers seem to work today as well. It must have been the logging out yesterday and back in today that reset everything. Thanks everyone!
0 -
Dynamic DNS stopped working too. Everything returns as "127.0.0.1" after update.
Ticket sent with information, logs, debugging, 96023875
"11.136.0.20 regression: cpsrvd no longer honors X-Forwarded-For from localhost. breaks cpanelwebcall, API-token allowlists, and client-IP attribution"1 -
I'm still receiving 'The login is invalid' even after clearing browser cache/cookies/new browser/private mode etc. for WHM and the same goes for all websites cPanel access. I also never setup 2FA.
0 -
@Christos Panagiotakis — confirming your finding from a different angle, on v11.110.0.127 (CentOS 7). This is not the browser-cache/relogin issue most of this thread is describing — it's the deeper server-side regression you identified: cpsrvd no longer honors X-Forwarded-For from the localhost proxy, so everything is seen as 127.0.0.1.
On top of the WHM login problem, it breaks webmail: Roundcube requests through the proxy now 502, with Apache logging
AH01102: error reading status line from remote server 127.0.0.1:2095— 938+/day since the update vs 1 the day before. A full cpsrvd restart (confirmed new PID) does not fix it, and clearing cache does nothing (it's not client-side). Cookie IP validation also rejects logins (cookie ip check → 127.0.0.1); onlycookieipvalidation=loosemasks that half.Direct access on
:2096(bypassing the Apache proxy) works perfectly — which isolates it to the localhost proxy → XFF/trusted-proxy path changed in this build. Same root cause as ticket 96023875. Please prioritize a fixed build for the v110 tier too, not just mainline — and note this regression is not resolved by relogin/cache-clear, despite what the WHM-login reports above might suggest.2 -
I see they just pushed 136.0.21 to the dashboard for install. Has anyone tried that one yet?
0 -
https://docs.cpanel.net/changelogs/136-change-log/#136-0-20
Here, resolutions mentioned.
0 -
Elvio Escobar I was able to resolve the webmail issue using the workaround here:
Service subdomains webmail/cpanel/webdisk/whm return error 502 when using ea-nginx as reverse proxy – cPanel0 -
I installed 136.0.21 and it removed the 2FA problem from before.
0 -
Edward de— thanks, that's a useful pointer! In my case though that workaround doesn't apply: this server runs plain Apache (EA4), no ea-nginx / reverse proxy in front, so there's no nginx layer to apply the
$PROXY_FORWARDED_HOSTfix to.The failure here is at the Apache → cpsrvd hop directly: Apache logs
AH01102: error reading status line from remote server 127.0.0.1:2095on Roundcube requests, ~938/day since the 11.110.0.127 update vs 1 the day before. Same underlying cause Christos described — cpsrvd no longer honoringX-Forwarded-Forfrom the localhost proxy, so everything is seen as 127.0.0.1 (ticket 96023875). A full cpsrvd restart doesn't clear it; direct access on:2096(no proxy) works fine.Quick question in case it helps others: was your server also on a post-update build (136.0.20 / 110.0.127), and did the nginx workaround actually change which client IP cpsrvd sees — or did it just re-route the service subdomains around the broken path? Trying to tell whether your fix addresses the same XFF regression or a separate ea-nginx config issue.
For reference, neither 110.0.128 (only a Perl DBI CVE, CPANEL-53905) nor mainline 136.0.21 (only the 2FA prompt fix, CPANEL-53691) addresses this XFF regression yet — so for plain-Apache servers there's still no released fix.
0 -
Ours is on 134.0.37. It looks like since I made the suggested workaround, the error line "AH01102: error reading status line from remote server 127.0.0.1:2095" has not returned.
0 -
I updated to 136.0.21, but I'm still out of luck (The login is invalid.) getting into WHM and domains can't access webmail/cPanel. cPRex any word from the dev team on this issue?
0 -
More details on this issue here: https://support.cpanel.net/hc/en-us/articles/41145021274007-Webmail-cPanel-failing-to-open-when-using-service-subdomain-Over-standard-port-expect-cpanel-service-subdomain-not-127-0-0-1
I've linked this thread to our case internally so I'll be sure to post an update as soon as I have one.
0 -
Thanks. The resolution provided does not work for my server.
0 -
Update - we're currently working on an update for this issue and hope to have it released tonight. I'll post more details as soon as I have them!
1 -
The update has been released so you can update your servers to version 136.0.22 now
0 -
cPRex Installed and rebooted, no joy 'The login is invalid.' for WHM and cPanel accounts.
0 -
Installed 136.0.22 and everything is running fine. Also no longer have to put my 2FA code in when accessing accounts. Thank you!
0 -
Dezdan - I think you're experiencing a different issue altogether. We'll probably need to see a ticket.
Michael Carnes - glad to hear it!
1 -
I'm in! I'm embarrassed to say I failed to check cphulk and when I dawned on me, yeah, I was blocked for brute force... I failed to whitelist myself in cphulk after my IP change. Doh!
0
Please sign in to leave a comment.
Comments
33 comments