It started as the kind of request that sounds like a two-minute job: “Can you put a note on the WHM login page?”
I want to note, for the record, that it was not a two-minute job.
The ask
We’d stood up a new box, and the plan was to redirect new site provisioning elsewhere while this one got sorted out. Someone didn’t get the memo and a new site was added to an old, outdated webhost we plan to decom. The ask was simple enough: put a banner somewhere an admin would see it before doing anything dumb, like adding a new account to a server that shouldn’t be getting new accounts.
“Just put a note on the login page,” I thought. WHM’s been around forever. Surely there’s a settings toggle for this.
There is not a settings toggle for this.
Wrong turn number one: the templates that aren’t templates
WHM ships with a templates directory — specifically /usr/local/cpanel/whostmgr/docroot/templates/ — containing a genuinely enormous number of .tmpl files, hundreds of them, covering every screen in the admin interface. Naturally, I assumed the login page lived in there somewhere, tucked away as login.tmpl or main.tmpl or something equally obvious.
It does not. That directory is entirely for the authenticated side of WHM — the screens you see after you’ve logged in. The login screen itself is handled somewhere else entirely, and finding it took a bit more excavation than “grep for the word login.”
Wrong turn number two: the file that used to matter
Eventually I found a directory structure clearly meant for exactly this purpose: /usr/local/cpanel/base/unprotected/, containing theme folders with files like login_whostmgrd.html, login_cpaneld.html, and login_webmaild.html — one login page per product, which is exactly the separation you’d want. WHM only, no bleed into the customer-facing cPanel login.
I edited /usr/local/cpanel/base/unprotected/cpanel-legacy/login_whostmgrd.html. Added a nice banner div. Confirmed the diff. Restarted the login service for good measure.
Refreshed the page. Nothing changed.
Turns out that file was a fossil — a leftover from an older theme generation (the cpanel-legacy theme folder, untouched since 2020), still sitting on disk, no longer wired up to anything. The actual login screen had moved on to a newer templating setup, in a sibling directory — /usr/local/cpanel/base/unprotected/cpanel/ — that happened to share almost the same filename. Classic.
The actual fix (login page)
The real file was /usr/local/cpanel/base/unprotected/cpanel/templates/login.tmpl, a Template Toolkit template that already had the exact logic I needed: an app_name variable indicating which product was rendering the page (whostmgrd, cpaneld, or webmaild), used to swap the logo and app name. That meant I could wrap my banner in a simple [% IF app_name == 'whostmgrd' %] conditional so it would only ever appear on the WHM screen — never the customer-facing login, even though they’re technically served by the same file.
One Python one-liner later (safer than fighting shell quoting with a file full of nested brackets and quotes), plus running /usr/local/cpanel/scripts/restartsrv_cpsrvd to kick the daemon that renders the login screen, and there it was: a small red banner, WHM login only, exactly as intended.
A brief and unplanned security detour
Somewhere in the middle of this, while researching how the login templating actually works, I ran across a very recent, very critical vulnerability affecting the exact daemon responsible for rendering that login page — CVE-2026-41940, an unauthenticated session-forgery bug that could hand an attacker a root session with no credentials at all. Rated about as high as these things get.
Good news: a version check showed the box was already on a patched build. Bad news, sort of: it was a reminder that the OS underneath was end-of-life, capped permanently on the last software tier that would ever run on it. Not the day’s project, but the kind of thing you write down and revisit soon.
Moral of the story: sometimes “add a banner” turns into a mini security audit, and that’s a feature, not a bug.
Round two: the dashboard
Banner installed, problem solved — except then came the follow-up request: also put a smaller note on the WHM landing page, the dashboard you see immediately after logging in.
This time the hunt was shorter, because I already knew not to trust the obvious templates directory blindly, and to go looking for unique, page-specific text instead of guessing filenames. WHM’s dashboard, it turns out, already has its own built-in banner system — the “your OS is dying, please upgrade” notices that show up automatically when you’re running something end-of-life. Searching for the literal wording of one of those notices led straight to the real dashboard template, /usr/local/cpanel/whostmgr/docroot/templates/menu/main.tmpl, sitting quietly under the authenticated-side templates directory after all (just not where I’d first guessed).
From there, dropping in a small custom notice — reusing WHM’s own warning-banner styling so it’d look native instead of like a hack — was almost anticlimactic. A single line, above all the other server-health chatter, that just said: don’t add anything to this box.
Later, that got upgraded again to include actual pointers to where new sites should go instead — plain links, opening in the same tab, no fuss.
Takeaways
A few things stuck with me:
Directory structure is not documentation. The presence of a templates folder full of .tmpl files told me almost nothing about which one, if any, controlled the page I actually cared about. Filenames lie, or at least go stale, and stale files don’t error — they just silently do nothing while you wonder why your edit isn’t showing up.
When an edit doesn’t show up, check two things before you start doubting yourself: did the file actually change, and is something caching the old version in memory. Both saved me a round of unnecessary self-doubt.
And finally: never underestimate how much a “just add a quick note” request can teach you about a system you thought you already understood.