The editorial argues that LastPass's four breaches in 44 months represent a pattern of structural failure, not isolated incidents. Each new notification compounds the risk of prior ones — particularly the catastrophic 2022 vault exfiltration — making the company's track record a matter of public record that disqualifies it from being trusted as a single point of failure.
The editorial emphasizes that the 2022 vault exfiltration — where URLs and metadata sat in plaintext and password fields were crackable offline — remains the defining event. Security researchers traced $35M+ in crypto thefts (Krebs, ZachXBT) to those stolen vaults, and users who didn't fully rotate after 2022 still carry that accumulating attack surface today.
The editorial frames password managers as 'a single point of failure by design' — acceptable only when the operator has earned trust. The LogMeIn-era LastPass has spent four years demonstrating the opposite, suggesting the architectural model itself becomes untenable once custodial trust erodes.
By submitting the 9to5Mac story to Hacker News where it reached 397 points and 175 comments, the submitter signals that yet another LastPass breach is significant enough to surface to the developer community. The high score and comment volume reflect broad community concern that this pattern is no longer dismissible as routine.
The article's framing — 'yet another data breach' — positions this disclosure within the established pattern rather than as an isolated event. 9to5Mac treats the recurrence itself as the story, signaling to readers that LastPass's serial breach history is the relevant context for evaluating the new notification.
LastPass has issued another breach notification, reported by 9to5Mac on June 23, 2026 and surfaced to the top of Hacker News with 397 points. The disclosure follows the same playbook the company has used since 2022: a measured statement, an assurance that master passwords were not directly exposed, and a recommendation that users rotate credentials and enable additional authentication factors.
This is the fourth significant security incident LastPass has publicly disclosed since August 2022, when an attacker first breached the development environment and used that foothold to eventually exfiltrate customer vault backups in November of that year. The 2022 incident remains the defining event: encrypted vaults containing URLs, usernames, and passwords were taken from cloud storage, and only the password fields themselves were encrypted with the user's master password. URLs and metadata sat in plaintext. Security researchers later traced a series of high-value crypto thefts — including the $35M Unciphered cluster documented by Brian Krebs and ZachXBT — to vaults from that breach being cracked offline.
The specifics of the 2026 incident at time of notification are limited, but the structural problem is not. LastPass operates as a centralized custodian of the most sensitive secrets a developer holds, and its track record over the last 44 months is now a matter of public record rather than speculation.
Password managers are, by design, a single point of failure — which is fine when the operator has earned the trust required to be that single point. LogMeIn-era LastPass has spent four years demonstrating the opposite. Each subsequent notification doesn't just add a new incident to the ledger; it compounds the risk profile of every prior one, because users who didn't fully rotate their vault after 2022 are now operating with an attack surface that's been accumulating for years.
The industry has not been silent on this. 1Password, Bitwarden, and Proton Pass have all shipped substantive architectural improvements in the same window — secret keys layered on top of master passwords, fully open-source server implementations, end-to-end encryption of vault metadata, and in Bitwarden's case, self-hostable infrastructure for teams that want to remove the SaaS trust assumption entirely. Wladimir Palant's deep dives on LastPass's iteration count defaults, encrypted-but-not-really fields, and slow security responses have been circulating for years. The Hacker News thread is dominated not by surprise but by a kind of tired vindication — comments along the lines of "how is anyone still using this" outnumber technical discussion of the breach itself.
There's a broader pattern here worth naming. The security posture of a custodial service is not what it claims in its trust center; it's the integral of every incident, every disclosure delay, and every architectural decision over time. A vendor that ships one breach badly can recover. A vendor that ships four breaches over four years, each with the same reassuring language and each followed by community discoveries that the initial disclosure understated the impact, has revealed something durable about its engineering culture. Trust, once spent, is expensive to rebuild — and LastPass has not visibly attempted the kind of public, auditable overhaul that would justify a second look.
For enterprises, the calculus is more painful. LastPass Enterprise deployments often involve thousands of seats, SCIM provisioning, hundreds of integrations, and SSO configurations that took quarters to roll out. Migration is real work. But the question CISOs are increasingly being asked in board meetings is not "what's the cost of migrating?" — it's "what's the cost of explaining, after the next incident, why we didn't?"
If you're an individual developer still on LastPass: treat your vault as compromised, not as something that might be compromised. Export it, import into 1Password or Bitwarden, and then — this is the part people skip — actually rotate the credentials, starting with anything tied to email recovery, financial accounts, cloud providers (AWS, GCP, Azure root and IAM), DNS registrars, GitHub, and crypto wallets. The order matters because email recovery is the master key to most of the rest. Use this as the forcing function to enable hardware-backed MFA (YubiKey, Touch ID passkeys) on the accounts that support it, which is now most of them.
For teams: this is the moment to revisit your secrets architecture more broadly. A password manager should be the storage layer for human-typed credentials only. Anything programmatic — API keys, deploy tokens, database credentials, service-to-service auth — belongs in a secrets manager (Vault, AWS Secrets Manager, Doppler, Infisical) with short TTLs, audit logs, and rotation automation. If your LastPass vault contains production database passwords because it was the convenient place to put them in 2019, the migration is also a chance to fix that.
For security-conscious teams that want the SaaS convenience without the trust assumption: Bitwarden's self-hosted server (Vaultwarden is the popular Rust reimplementation) runs comfortably on a single VPS, integrates with the same client apps, and removes the custodial-breach risk entirely. The operational overhead is real but bounded — it's a single container, a Postgres instance, and a backup job.
The password manager market is in the middle of a quiet consolidation around architectures that minimize the trust users have to extend to the vendor. Passkeys, hardware-backed authentication, and end-to-end-encrypted metadata are moving from differentiators to table stakes — and the vendors who shipped them first are pulling away from the vendors who didn't. LastPass's continued presence in enterprise procurement decks is increasingly a function of switching costs rather than security posture, and switching costs erode every quarter as competitors ship better migration tooling. The fourth breach notification in four years isn't the end of LastPass, but it's another data point in a trend line that, at some point, becomes a decision.
Lots more companies affected. Some more listed below:>"Klue has not said how many of its hundreds of customers are affected. Several companies have come forward to confirm they had data stolen during the attack, including Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Spro
https://blog.lastpass.com/posts/klue-supply-chain-incident-a...> The information accessed was limited to standard business contact information and related customer relationship management (CRM) data, including customer names, phone numbers, email addresses, and physical addres
WTF is LastPasd doing, handing customer details to a market research company? Any such data should have been fully anonymized: no names, no specific addresses, etc..For anyone looking for a recommendation: I use KeepassXC with Keepass2Android. Open source, with a local database that you can choose t
I'm sure this is worse than using lastpass in some waybut for the past couple years I've just generated and forgotten 90% of my passwords. the final 10% I keep in a password manager. But if the service isn't really that important I just use the 'forgot my password' to change
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
How does anyone seriously trust LastPass anymore? Years ago, I was working for a company handling bank data. They were using LP immediately following a previous LP security incident and had no plans to migrate away.