Okta · · incident month
Okta support-system incident
Okta reported unauthorised access to its customer-support system and files supplied with support cases. The support system was separate from its production identity service.
Breach family tree
Follow reported connections between incidents: where stolen access or a supplier compromise led to another incident, and what happened next.
Every published connection has a source review and links explaining it. Branches describe reported access paths, not blame, legal responsibility, or proof that the same actor conducted every incident. Contained access and customer-data exposure are shown separately.
3 incident records · 2 reviewed connections. Starting with a small set of researched reports; this is a curated archive, not a complete or automatically verified breach tracker.
Okta support-system incident
- Stolen session token reused
Cloudflare connected the October access to a session token taken from an Okta support case.
Access reported and contained
Cloudflare · · incident month
Cloudflare identity access, contained
Cloudflare reported access to its Okta environment using a stolen support-case session token. It contained the access and reported no impact to customer information or systems.
Evidence and limits of this connection
Contained access is not the same as a customer-data breach. This connection describes Cloudflare's reported identity-environment incident.
Source review: . A review records our reading of the cited reports; it is not an independent forensic investigation.
- Stolen credentials reused
Cloudflare said credentials stolen during the Okta compromise were later used to enter its internal Atlassian environment.
Internal compromise reported
Cloudflare · · incident month
Cloudflare internal Atlassian incident
Cloudflare reported unauthorised access to internal documentation and source-code systems. It attributed initial access to credentials stolen during the earlier Okta incident that it had not rotated.
Evidence and limits of this connection
Cloudflare reported no customer-data or customer-system impact. It did not attribute this to a breach of Atlassian or the other vendors whose service credentials were involved.
Source review: . A review records our reading of the cited reports; it is not an independent forensic investigation.
How connections get here
Stories mentioning the same organisations can become private review leads. A co-mention alone never creates a public branch. Before a connection is added, its direction, mechanism, scope and sources are reviewed. New records are approved locally and published with the next site update.
Incident months describe when activity occurred or was reported in the cited account, not the date we added it. A missing branch means we have not published that connection, not that no other organisations were affected.
Use this to understand supplier dependencies and incident response. The campaign workbench can help map a report's observed behaviour to ATT&CK.