Substack data leak exposes account metadata and phishing risk

At a glance

What this is: Substack experienced a data breach that exposed user account metadata and contact details, then saw the dataset circulate on cybercrime forums.

Why it matters: This matters because identity and access teams must treat contact data, profile data, and internal metadata as abuse-enabling assets, not just privacy fields, especially where SaaS platforms support large creator and subscriber ecosystems.

By the numbers:

• The breach was discovered on February 3, 2026, after it reportedly occurred in October 2025.

👉 Read Gurucul's analysis of the Substack data leak and identity exposure

Context

Substack’s breach is a reminder that SaaS account data can become an identity security problem even when credentials are not directly stolen. Contact details, usernames, bios, and internal metadata can be repurposed for phishing, smishing, impersonation, and targeted social engineering across the broader ecosystem.

For IAM and security teams, the governance issue is not limited to password compromise. When a platform exposes identity-adjacent data at scale, attackers gain the context needed to weaponise trust, craft convincing lures, and widen the blast radius beyond the original application boundary.

Key questions

Q: What breaks when SaaS account data is exposed even if passwords are not stolen?

A: When account data is exposed, attackers can still mount convincing phishing and impersonation campaigns using email addresses, phone numbers, usernames, profile names, and internal metadata. That information increases trust in malicious messages and helps attackers correlate records across systems. Security teams should treat identity context as exploitable, not harmless.

Q: Why do exposed profile fields and contact details matter to IAM teams?

A: They matter because IAM controls are only one part of identity security. If profile fields and contact details are widely exposed, attackers gain the context needed to target users, support staff, and admins with believable lures. That widens the attack surface beyond authentication and into social engineering.

Q: How do security teams know whether account-data exposure is being contained?

A: They should look for rapid reduction in external references to the leaked dataset, lower levels of anomalous bulk access, and fewer successful phishing attempts using exposed identity details. If the same records keep reappearing on forums or in lure campaigns, containment has not been achieved.

Q: Who is accountable when a platform exposes user identity data at scale?

A: Accountability sits with the organisation that controls the data, the privileged access paths, and the detection process around those records. Security, application, and privacy teams all share responsibility, but the owner of the exposed system must ensure access review, monitoring, and incident response are effective.

Technical breakdown

How exposed account metadata becomes an attack asset

Account metadata is often treated as low-risk because it is not a credential, but that assumption is weak. Email addresses, phone numbers, usernames, profile names, and bios help attackers validate identities, target users with believable lures, and correlate records across datasets. Internal account metadata adds an even richer layer because it can reveal account structure, status, or administrative context. In SaaS environments, that combination can support phishing at scale without requiring password theft.

Practical implication: classify identity metadata by abuse potential, not just sensitivity.

Why delayed detection increases the downstream impact

A detection gap gives attackers time to copy, package, and redistribute data before defenders can contain the exposure. Once a dataset appears on cybercrime forums, the organisation loses control of the audience, the retention period, and the reuse cycle. The risk shifts from single-incident exposure to repeated abuse across phishing campaigns, credential harvesting attempts, and impersonation. In practice, the breach becomes a source of ongoing exploitation rather than a one-time event.

Practical implication: tune monitoring for bulk extraction and secondary redistribution, not only initial access.

Least privilege and administrative monitoring in SaaS data stores

The article’s mitigation steps point to a familiar control gap: excessive access to account data and weak monitoring of administrative activity. Least privilege is not only about application functions, it also applies to who can query, export, or inspect user records and internal metadata. Where data stores support bulk export or privileged queries, access should be tightly scoped, logged, and reviewed. Otherwise, even limited initial access can turn into large-scale exposure.

Practical implication: review privileged database and support access against the principle of minimum necessary access.

Threat narrative

Attacker objective: The attacker’s objective was to obtain and redistribute identity-rich account data that could be monetised or reused for phishing and social engineering.

1. Entry occurred when an unauthorized party accessed limited Substack user account data through the underlying vulnerability described in the incident.
2. Escalation followed as the exposed records were gathered into a dataset containing contact details, profile data, and internal metadata suitable for misuse.
3. Impact came when the leaked dataset was posted on cybercrime forums, increasing phishing, spam, and social engineering risk for affected users.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity metadata is an abuse-enabling asset, not a background field. This breach did not need password compromise to create material security risk because contact details and profile context are enough to enable believable impersonation. The lesson is that identity governance must cover the data surrounding identities, not only the credentials that authenticate them. Practitioners should treat exposed metadata as part of the identity attack surface.

Four-month detection gaps turn SaaS exposure into a redistribution problem. The longer a breach remains undiscovered, the more likely the data will be copied, aggregated, and reposted in places defenders cannot control. That shifts the problem from incident response to persistent abuse of the same records across multiple campaigns. The implication is that visibility into bulk extraction matters as much as access control itself.

Least privilege for SaaS must extend to support paths, exports, and internal metadata access. Organisations often scope privilege around application features while leaving rich account data reachable through administrative or analytical paths. That creates a hidden identity blast radius: a small access failure can expose records that power broad phishing and impersonation efforts. Practitioners should revisit who can query, export, and inspect user data.

Phishing resilience now depends on data minimisation across identity-adjacent fields. Many teams still focus on passwords and payment data while leaving bios, usernames, and profile metadata broadly available. Those fields can be enough to make social engineering materially more convincing. The governance conclusion is simple: reduce the volume and reach of identity context that attackers can reuse.

Substack illustrates the governance gap between account compromise and account exploitation. The breach shows that an incident is not limited by what was technically accessed in the first moment. Once identity-rich records are exposed, the downstream risk extends into the user lifecycle, support operations, and cross-platform targeting. Practitioners need to manage the exploitation path, not just the intrusion path.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to Oasis Security & ESG.
• From our research: Review the NHI Lifecycle Management Guide for offboarding and access-review patterns that help limit reuse after exposure.

What this signals

Identity blast radius: when account metadata escapes, the issue is not only disclosure but reuse. Teams should assume exposed profile and contact data will be folded into phishing, smishing, and impersonation campaigns, which makes minimisation and access scoping an operational control rather than a privacy preference.

The practical signal for practitioners is simple. If bulk export paths, support tooling, and administrative queries are not continuously reviewed, a small access failure can create a long tail of abuse. That is why data-access governance must be measured alongside authentication coverage and logging quality.

With two-thirds of enterprises having already endured a successful cyberattack tied to compromised non-human identities, per The 2024 ESG Report: Managing Non-Human Identities, identity teams should expect attackers to reuse any available identity context. The programme response is to reduce what can be repurposed, not just what can log in.

For practitioners

• Classify identity metadata by abuse value Inventory which user fields, internal metadata elements, and support records can be used for phishing, impersonation, or account correlation. Protect those datasets with the same discipline used for credentials and privileged secrets.
• Review bulk export and support access paths Identify every role that can query, export, or inspect account records at scale, then verify least-privilege scoping, logging, and periodic access review for those paths.
• Detect secondary redistribution quickly Monitor cybercrime forums, messaging channels, and paste sites for redistributed datasets so a breach does not become a long-lived abuse source. Use anomaly detection on large exports and unusual query patterns to shorten dwell time.
• Harden user messaging against impersonation Prepare phishing awareness guidance that references exposed contact and profile data, not just generic breach language. Users need to understand that accurate personal details increase the credibility of malicious messages.

Key takeaways

• This breach shows that identity-adjacent metadata can be weaponised even when passwords and payment data are untouched.
• The scale of exposure and the four-month discovery gap increase the likelihood of repeated phishing and impersonation abuse.
• Least privilege, export monitoring, and data minimisation across account records are the controls most likely to limit similar incidents.

Key terms

• Identity Metadata: Information that describes or contextualises a user account, such as email address, phone number, username, profile name, or internal record attributes. It is not a credential, but it can materially increase an attacker’s ability to impersonate, correlate, or target an identity across systems.
• Data Redistribution: The reposting or resale of stolen data after an initial breach, often on cybercrime forums, messaging channels, or paste sites. In identity incidents, redistribution extends harm because the same records can be reused repeatedly for phishing, spam, impersonation, and fraud.
• Identity Blast Radius: The amount of downstream harm created when identity-related data or access is exposed. It includes the number of users affected, the reuse potential of exposed fields, and the number of follow-on attacks that can be launched from the same records.
• Bulk Export Access: A privileged capability that allows large-scale extraction of records from a system, often through admin tools, APIs, or support workflows. In identity programmes, this access requires strict scoping, logging, and review because it can turn a limited breach into a broad disclosure event.

What's in the full article

Gurucul's full blog covers the operational detail this post intentionally leaves for the source:

• The incident timeline and the specific discovery sequence that led to public confirmation.
• Sample leak details and the account fields exposed in the dataset.
• The detection and structural control recommendations the source proposes for SaaS environments.
• The incident assessment and severity framing applied to the breach.

👉 Gurucul's full post covers the breach timeline, leaked data samples, and recommended controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.