{"name":"SaaS Breach-Pattern Dataset","description":"A structured catalog of notable SaaS/vendor data breaches classified by the underlying architectural pattern (vendor-held keys, vendor-side cleartext, third-party auth compromise, downstream-vendor data, insider threat). Each entry cites a public source. Compiled by Koaich; based on public disclosures, not independent investigation.","version":"2026","license":"https://creativecommons.org/licenses/by/4.0/","license_short":"CC-BY-4.0","attribution":"Source: Koaich SaaS breach-pattern dataset (https://koaich.com/breaches). Licensed CC-BY 4.0.","canonical":"https://koaich.com/breaches","methodology":"https://koaich.com/methodology","corrections":"hello@koaich.com","disclaimer":"Based on public breach disclosures. Pattern classification reflects a privacy-architecture lens. Email corrections to hello@koaich.com.","breach_count":6,"patterns":{"vendor-held-keys":{"label":"Vendor-held keys","framing":"The vendor was holding decryptable copies of customer secrets. Attacker breach yielded the keys + the data; cryptography didn't bound the exposure."},"vendor-side-cleartext":{"label":"Vendor-side cleartext","framing":"The vendor's runtime services hold customer content as cleartext to operate. Attacker access to those services yielded readable customer data directly."},"third-party-auth-compromise":{"label":"Third-party auth compromise","framing":"The vendor's identity provider or auth-adjacent third party was breached; downstream customer accounts inherited the trust failure."},"downstream-vendor-data":{"label":"Downstream vendor data","framing":"A data-warehouse or cloud-service vendor holding customer data on behalf of many downstream tenants was breached; every tenant's data was exposed at once."},"insider-threat":{"label":"Insider threat","framing":"A vendor employee with legitimate admin access abused their position. The cryptographic boundary didn't exclude that role from cleartext access."}},"breaches":[{"id":"lastpass-2022","vendor":"LastPass","date":"2022-08","title":"LastPass vault backup exfiltration","plain_english":"Attackers stole copies of every LastPass user's password vault. The passwords inside the vaults stayed encrypted, but the URLs of every site each user had a password for — plus their names and emails — were stored in plain text, and those leaked.","summary":"Attackers stole encrypted password vaults plus unencrypted vault metadata (URLs, account holder emails). The vault contents themselves remained encrypted under each user's master password — the architectural property worked as designed.","what_exposed":"Encrypted vault blobs for all customers, plus unencrypted URLs, names, email addresses, billing data, and IP addresses. The vault encryption used 100,100 PBKDF2 iterations (later contested as too few), so brute force against weak master passwords was feasible.","root_pattern":"vendor-held-keys","root_pattern_label":"Vendor-held keys","source_label":"LastPass disclosure timeline","source_url":"https://blog.lastpass.com/posts/notice-of-recent-security-incident"},{"id":"okta-support-2023","vendor":"Okta","date":"2023-10","title":"Okta customer-support system compromise","plain_english":"Okta is the company most large businesses use to sign people in to all their other apps. Attackers got into Okta's customer-support system and stole files customers had shared with Okta's support staff. Those files contained login session info that let attackers try to break in to those customers' own systems.","summary":"Attackers obtained HAR files (browser session recordings, including authentication tokens) uploaded by Okta customers to Okta's support portal during troubleshooting. Several downstream Okta customers — including 1Password and BeyondTrust — detected attempted account takeover attacks linked to leaked tokens.","what_exposed":"Authentication tokens and session data for an estimated 134 Okta customers. Downstream impact at customers who used Okta SSO for their workspace tools.","root_pattern":"third-party-auth-compromise","root_pattern_label":"Third-party auth compromise","source_label":"Okta security advisory","source_url":"https://sec.okta.com/harfiles"},{"id":"microsoft-storm-0558-2023","vendor":"Microsoft 365","date":"2023-07","title":"Storm-0558: stolen Microsoft signing key access to government Exchange Online","plain_english":"Hackers linked to the Chinese government stole a master key Microsoft uses to prove its own identity to its services. With that key, they could fake being any Microsoft customer — including U.S. federal agencies — and read their email. They had access for about a month before anyone noticed. The key existed because Microsoft holds it; if Microsoft hadn't held the key, the attackers wouldn't have had anything to steal.","summary":"A China-linked threat actor obtained a Microsoft Account (MSA) consumer signing key and used it (combined with a token-validation flaw) to forge tokens for ~25 Microsoft 365 customer organizations, including US federal agencies. Attackers accessed cloud email inboxes for an estimated month before detection.","what_exposed":"Exchange Online mailboxes for ~25 affected organizations. The vendor had decryption capability over customer mail by default; once an attacker gained the vendor's keys, customer content followed.","root_pattern":"vendor-held-keys","root_pattern_label":"Vendor-held keys","source_label":"CISA + Microsoft incident reports","source_url":"https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a"},{"id":"microsoft-midnight-blizzard-2024","vendor":"Microsoft","date":"2024-01","title":"Midnight Blizzard: Russian APT in Microsoft corporate Exchange","plain_english":"Russian state-linked hackers got into Microsoft's own internal email — for weeks. They read messages from Microsoft's senior leadership and security teams. Microsoft eventually disclosed that the same attackers got into some of Microsoft's source code. The attack worked because Microsoft's own employees, like all Microsoft 365 customers, use Exchange Online where Microsoft holds the keys.","summary":"Russian state-affiliated actor Midnight Blizzard (a.k.a. APT29, Cozy Bear) gained access to Microsoft corporate email accounts including senior leadership and security team. Microsoft later disclosed source-code repositories were also accessed.","what_exposed":"Microsoft executive and security-team emails; Microsoft source code repositories. The attack persisted for weeks because Microsoft's tooling held cleartext access to its own employees' email.","root_pattern":"vendor-side-cleartext","root_pattern_label":"Vendor-side cleartext","source_label":"Microsoft Security Response Center disclosure","source_url":"https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/"},{"id":"snowflake-2024","vendor":"Snowflake-downstream (AT&T, Ticketmaster, Santander, others)","date":"2024-05","title":"Snowflake-cluster credential reuse: tens of millions of records per tenant","plain_english":"Snowflake is a service big companies use to store their customer data. Hackers got the login passwords for about 165 of Snowflake's customer accounts that didn't have two-factor auth turned on. With those passwords, they walked in and copied huge customer databases. AT&T lost 110 million call records. Ticketmaster lost 560 million customer accounts. Snowflake itself wasn't broken into; the customers' passwords were. But once an attacker had a valid login, all the data was sitting there as plain readable rows.","summary":"Attackers used credentials harvested from infostealer malware to access ~165 Snowflake-tenant accounts that lacked MFA. Downstream impact: AT&T (110M call records), Ticketmaster (560M accounts), Santander, LendingTree, and others. Snowflake itself wasn't breached — customer-managed credentials were.","what_exposed":"Customer records held by Snowflake on behalf of dozens of major downstream tenants. The data was readable to anyone with valid Snowflake credentials because Snowflake's customer environments hold cleartext.","root_pattern":"downstream-vendor-data","root_pattern_label":"Downstream vendor data","source_label":"Mandiant analysis of UNC5537","source_url":"https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion"},{"id":"slack-tokens-2022","vendor":"Slack","date":"2022-12","title":"Slack-employee token theft via GitHub access","plain_english":"Attackers got login credentials for a few Slack employees and used them to read Slack's source code on GitHub. Slack disclosed that no customer messages were accessed — they keep source separate from production data. A bounded incident, included here as an example of what happens when a company keeps the right separations.","summary":"Attackers obtained a small set of Slack employee tokens via compromised third-party services, then accessed Slack's externally-hosted GitHub repositories. No customer data or Slack production services were accessed per Slack's disclosure.","what_exposed":"Slack source-code repositories. Notably bounded — Slack's separation of source from production data limited the impact.","root_pattern":"third-party-auth-compromise","root_pattern_label":"Third-party auth compromise","source_label":"Slack security incident notice","source_url":"https://slack.com/intl/en-gb/blog/news/slack-security-update"}]}