The website login said cookies were blocked
A login that failed at random hid a worse fault: the site served a logged-in administrator's page to anyone. Fifty-six emails were stuck as well.
You try to log in to the admin area of your company’s website. It worked a minute ago, and now it says the password is wrong, or sometimes that cookies are blocked or not supported. You changed nothing. The owner of the site told us the password “worked for a second and then stopped”.
The obvious suspect was a lockout. It was not one, and the real findings were two quieter faults that had nothing to do with the password. One was a change that could never complete because the email needed to confirm it could not leave the server: 56 messages, password resets among them, were stuck in the outbound queue. The other was worse. The site was showing a logged-in administrator’s view of the page to anonymous visitors.
What was actually going on
The login plugin’s own log gave the timeline. A successful login, a logout three minutes later, then seven failed attempts with a valid username and a wrong password. A valid username with a wrong password is not a lockout. The password had simply been changed, and we confirmed that by testing the candidate passwords against the stored hash on our own machine, rather than typing them through a remote command that the cloud account would have kept a record of.
What the owner was actually chasing was a change of the site’s administrator email. WordPress holds that kind of change until somebody clicks a confirmation link sent to the new address. The link never arrived, because the cloud provider blocks outbound mail on the standard port and the server was sending through a stopgap that relied on it.
The cache fault was separate. The site sits behind a content network that had been told to keep a copy of every page, with no exception for the hidden login page or for people who are logged in. Two things followed. The login page was stored without the small test cookie it sets, and a login form that arrives without that cookie says cookies are blocked, on and off, depending on which copy you got. And on 10 August the network was serving a logged-in administrator’s page to the public, admin bar, name and username included. It also served an unpublished draft page, with an internal review note on it. The contact page and the equipment page were doing the same.
What we changed
We applied the email change directly, then moved the site’s mail to the provider’s own mail service, using the permissions already attached to the server so that no password or key is stored anywhere. We sent a real message through it and read the delivery record, rather than trusting that the send call returned true.
For the cache, we patched only the one rule that let the login path through, verified every variation of the address and the logged-in cookies, and purged the stored copies. The token we were given could see 14 sites, so we confirmed that only the intended one changed. The test cookie now arrives, and the admin bar appears on none of the public pages we sampled.
What it did not fix
The domain’s sender record does not authorise the new mail route. Mail is accepted because its signature passes, but the record should be restructured, and that touches the company’s main email, so it needs the owner’s sign-off. About 58 old undeliverable messages remain in the queue. Alert emails still go to a former address.
We also left the server’s mail permission broader than it needs to be. It is shared by three servers and narrowing it risks breaking the app’s own one-time codes. The proper answer is a separate role for the website.
The pattern, for anyone whose site sits behind a cache
If a login fails for no reason, look at the page the visitor received, not only the password. Then log out, open the site in a private window and look for a toolbar, your name, or a page you have not published. If any of them is there, the cache is keeping copies it should not.
Where this ends up
The owner asked about a password and the real risks were a cache and a mail queue. Finding that takes someone who reads the server, not the screen, and that is the work of our custom software development team.