People treat 123456 like a museum piece. Password managers won the consumer fight, MFA boxes got checked, and the interesting cybersecurity work moved on to least-privilege platforms and models that help agents score their next move. Then almost 9 million personal records spilled because a very weak password was still sitting on a live system, inside a series of security failures any brute-force script would have loved. You can announce a $1.3 billion access acquisition this week. You cannot acquire your way out of a login prompt that still takes six sequential digits.

Least Privilege Still Starts With a Guessable Secret

IonQ just agreed to buy Elisity for up to $1.3 billion in an all-stock deal that folds least-privilege access technology into a quantum computing company’s security portfolio. On the same news cycle, Microsoft put a small scoring model, Decision-1, in front of AI agents so they can attach calibrated probabilities to a fixed set of next moves: routing, classification, prioritization, verification, workflow control. The industry reaction writes itself. Access is getting smarter. Agents are getting a pause button. You should feel safer.

Feel it for a second, then look at the login page.

Least privilege is a decision about what a session is allowed to touch after you believe you know who showed up. Decision-1 is a decision about what an agent should do after you believe the prompt is trustworthy. A password of 123456 answers both questions for whoever typed it. The real problem here is the gap between the access story you are funding and the credential still sitting in production. If the attacker authenticates, your cyber security program has already granted them a user-shaped hole in the perimeter.

This is a bad look for teams that spent the year briefing the board on zero trust while an intern-era password, a forgotten CMS, or a vendor portal never got the same scrutiny. Expensive controls on top of a trivial secret are stage dressing. The session looks legitimate because it is legitimate. Your stack issued the ticket.

Cybersecurity Still Dies on the First Guess

Malwarebytes walked through how 123456 became the key to almost 9 million personal records. Read that sentence again. Not a novel implant. Not a quantum-safe argument. A password your own policy documents already forbid, paired with other failures that let that secret become a full export of people’s lives.

You will not get every internal detail from a news write-up, and you should not wait for them. The pattern is enough. Somewhere an internet-reachable service accepted a guessable credential. Somewhere MFA was missing, skipped, or scoped to the “real” apps. Somewhere lockouts did not fire, logs did not page, and threat detection treated a successful login as health. Somewhere a pile of personal data was sitting behind that one door because nobody had done the unglamorous work of asking what happens if the password is the password.

Operators like to believe threat-protection is the camera pointed at malware. That camera stays quiet when the attacker uses the front door. Firewall policy that only argues about ports will pass the session; 443 is supposed to be open. Brute-force against 123456 is not a sophisticated campaign. It is a short dictionary and enough patience to survive your lack of lockout. If you only alert on volume, a slow guess still wins. If you only alert on failures, the one success is the incident.

Defense in depth at the identity plane is dull on purpose. Ban known-bad passwords at the IdP. Require MFA on every internet-facing human and service console, including the ones that “only the webmaster uses.” Cap failed attempts and put an ipban on the source. Watch successful authentications with the same seriousness you watch drops: new ASN, first-time admin, password-only on an account that should have been phishing-resistant. Security hardening that never inspects the password file is hardening of everything except the thing that issued the keys.

The other “solved” problem is still a plugin

The same week, Bricksforge, a WordPress plugin tracked as CVE-2026-85097, was reported exploited in the wild with enough reach to take control of targeted sites. You already know this plot. A CMS add-on with more privilege than the marketing team that installed it. A patch that existed for someone else first. A public exploit that does not care about your change window.

Connect it to 123456 or you will miss the operational rhyme. Full site control through a plugin and full record export through a guessable password are both failures of assumed hygiene. Somebody believed the platform vendor, the host, or last year’s audit had handled the boring layer. The attacker used the boring layer.

Treat wp-login, plugin update screens, and host control panels as privileged identity, not as content tooling. Inventory every public WordPress property, including the campaign microsite nobody migrated. Remove plugins you cannot name an owner for. Patch on the vendor’s timetable, not yours. Put admin interfaces behind SSO or a restricted source list so the whole internet is not invited to brute-force the same 123456 that just dumped 9 million records for somebody else. If the site owner password is reused from email, the plugin CVE is a second key to the same house.

Ban the Trivial Login Before You Shop for Access

You do not need a new least-privilege platform to do this week’s work. You need a list, a change ticket, and a refusal to treat “we have MFA somewhere” as coverage. Do the immediate work on internet-facing auth first, then keep the same controls alive after the incident ticket closes.

1. Enumerate every internet-facing login: IdP, VPN, cloud consoles, WordPress, host panels, databases, NAS devices, “temporary” admin paths, and vendor portals that still use local accounts. If you cannot name an owner, treat it as exposed.
2. Enforce a banned-password list that includes 123456, password, qwerty, welcome, and season-plus-year variants. Force rotation on any hit, including service accounts with static secrets in config or runbooks.
3. Require MFA on every one of those surfaces, including CMS admin and backup consoles. Password-only on an internet-reachable admin page is an open invitation, not a legacy exception.
4. Turn on lockout after a small number of failures and ban the source. If you already run something like IPBan Pro for failed-login bans, keep it pointed at VPN, RDP, SSH, and web admin; an ipban is containment, not proof the underlying password was any good.
5. Find Bricksforge and every other WordPress plugin you cannot justify. Patch or remove on the same day you learn the CVE is in the wild. Restrict wp-login.php and /wp-admin to known admin networks at the firewall so the plugin’s login page is not a public brute-force target.
6. Point threat detection at successful logins, not only at malware and failed passwords. Page on first-time admin, password-only where MFA should exist, and reuse of the same account from a new ASN. That is how you catch 123456 after it works.
7. Write the incident response path for valid credentials in hostile hands: revoke sessions, rotate secrets, search for password reuse across CMS, VPN, and cloud, and export-block the data stores that sat behind that login. Keep doing the password and plugin audit quarterly so security hardening does not expire when the board deck moves on.

None of that requires a quantum company’s new security portfolio. It requires you to stop assuming the guessable login died in 2012 because the training slide said so.

Frequently Asked Questions

Should we still hunt for 123456 if MFA is already on?

Yes. MFA gets skipped on legacy protocols, mis-enrolled apps, and “break glass” accounts that never got retired. A guessable password is still a reusable secret for the next system that forgot the second factor.

Does a least-privilege purchase replace password hygiene?

No. Least privilege decides what a session can touch after you believe the login. 123456 makes that belief cheap to steal, and the platform will happily enforce a tight policy for the attacker.

How should incident response change after a credential dump?

Hunt successful authentications, not only failures. Revoke sessions, rotate every reused secret, and check whether the same password opened the CMS, the VPN, and the cloud console. The export usually starts after a login your tools called healthy.

Sources

• How “123456” became the key to almost 9 million personal records
• IonQ to Acquire Zero Trust Firm Elisity for Up to $1.3 Billion
• Microsoft’s new model helps AI agents judge their next move
• Bricksforge WordPress Plugin Vulnerability Exploited in the Wild