Substack data breach exposes API and access control gaps

At a glance

What this is: FireCompass reports that Substack's October 2025 breach exposed 697,313 user records through phishing, exposed APIs, and inadequate access controls.

Why it matters: For IAM and NHI practitioners, the case shows how weak API authorization, token handling, and metadata exposure can turn a limited breach into a phishing-enablement event across identity and application layers.

By the numbers:

• 17 minutes.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read FireCompass's analysis of the Substack data breach and API access failures

Context

API exposure and weak access control can be enough to turn a platform incident into a broader identity risk. In this case, the primary harm was not credential theft or financial compromise, but the leakage of personal and operational metadata that can be weaponised in phishing and account takeover attempts. The primary issue is not unique to one platform; it is a common failure pattern wherever API authorization, token scope, and exposed metadata are not governed tightly enough.

For identity and security teams, the governance question is how much sensitive data can be reached through an API before a trust boundary is breached. That matters for IAM because OAuth tokens, access scopes, and revocation controls can become the real containment line, and for NHI governance because service tokens and machine-to-machine access often outlive the controls that were meant to constrain them.

Key questions

Q: What breaks when exposed APIs return more data than users should see?

A: Overexposed APIs turn a limited access event into a broader identity risk because attackers can collect email addresses, phone numbers, and internal metadata for reconnaissance and phishing. The breach may not include passwords, but the leaked data still increases impersonation success and account takeover pressure. The failure is often authorization scope, not just code quality.

Q: Why do weak API access controls increase phishing risk after a breach?

A: Weak API access controls let attackers harvest structured personal data at scale, which makes phishing messages more believable and targeted. Even without credentials, a dataset of names, contact details, and internal metadata improves social engineering, password reset abuse, and help desk impersonation. The risk rises when token scope and response filtering are not tightly governed.

Q: How can security teams tell if API exfiltration is happening?

A: Look for sequential record access, repeated calls to the same endpoint, unusual request volume, and data pulls that exceed normal user behaviour. Those patterns often appear before the breach is obvious to analysts. Strong monitoring should focus on extraction behaviour, token reuse, and the shape of requests rather than only on login failures.

Q: How should teams govern API access when regulated data is exposed through endpoints?

A: Teams should govern API access the same way they govern any other regulated access path: define ownership, classify data, set least-privilege permissions, and require evidence that authentication and authorisation are working in production. APIs often combine human, partner, and machine access, so lifecycle controls and review cadence matter as much as the code.

Technical breakdown

How exposed APIs turn metadata into an attack surface

APIs often expose more than application data. When endpoint permissions are too broad, even read-only access can reveal email addresses, phone numbers, internal identifiers, and account relationships that support reconnaissance and phishing. The risk is amplified when responses include metadata fields that were never meant for external consumption. In practice, attackers do not need credentials or payment data to create harm. They only need enough structured information to improve targeting, impersonation, and downstream social engineering.

Practical implication: restrict API responses to the minimum field set needed for each use case and review metadata exposure as part of authorization design.

Why token scope and revocation matter in cloud applications

OAuth and similar bearer tokens are only as safe as the permissions attached to them and the revocation process behind them. If token reuse is possible, or if scopes are broader than the task requires, an attacker who gains access can automate extraction and persist longer than intended. This is especially dangerous in distributed SaaS platforms where many services share the same access patterns. Strong token governance means scoping tightly, revoking quickly, and monitoring for abnormal request volume or pattern changes.

Practical implication: enforce narrow token scopes and immediate revocation paths for any token associated with exposed APIs.

What data exfiltration looks like when access control is weak

Data exfiltration through APIs often appears as normal application traffic at first. The telltale pattern is repeated calls, sequential enumeration, and extraction volumes that exceed typical user behaviour. FireCompass's analysis also points to anomalous API calls and unusual data extraction patterns, which are exactly the kinds of signals that should trigger investigation. This is a control and monitoring problem, not just a breach-response problem. If access policies, logging, and anomaly detection are thin, the attacker can leave with large datasets before containment begins.

Practical implication: baseline normal API usage and alert on high-frequency enumeration, unusual field access, and token reuse anomalies.

Threat narrative

Attacker objective: The attacker sought to extract user and metadata at scale, then use the resulting dataset to enable phishing and further identity abuse.

1. Entry occurred through phishing that gave attackers initial access to the environment and exposed APIs.
2. Escalation followed through inadequate access controls and token reuse vulnerabilities that enabled automated scraping via API endpoints.
3. Impact was the theft of 697,313 records, creating a phishing-ready dataset of email addresses, phone numbers, and internal metadata.

NHI Mgmt Group analysis

API access governance is now an identity problem, not just an application problem. When exposed APIs reveal personal metadata, the control failure sits at the boundary between authorization, session handling, and data minimisation. IAM teams should treat API scopes, token lifecycle, and response filtering as part of the identity control plane, not as a separate developer concern.

Metadata exposure is a phishing multiplier. Even without credential theft, leaked email addresses and phone numbers materially improve impersonation, targeting, and account recovery abuse. That means breach severity must be assessed by downstream exploitability, not only by whether passwords or payment data were exposed.

Standing API access creates a hidden trust boundary. This breach illustrates the governance gap created when service access persists beyond the context that justified it. The named concept here is exposed API trust leakage, where data access, token scope, and monitoring fail together and allow extraction before containment.

NHI governance applies whenever machine-to-machine access can enumerate user data. Service tokens, OAuth clients, and internal API keys can become non-human identities with real blast radius if they are not scoped, rotated, and audited against actual use. The lesson is to govern machine access with the same lifecycle discipline used for human privileged access.

Access control evidence should be measured against exfiltration patterns, not policy text. This incident shows why controls that look strong on paper can still fail operationally if logs do not surface anomalous call patterns, sequential extraction, or token reuse. Practitioners should validate control effectiveness through observable abuse paths, not declarations of least privilege.

What this signals

Exposed API trust leakage is the pattern practitioners should watch for next. As machine-to-user and machine-to-machine access expands, organisations will keep discovering that the breach boundary is not just login control but what an authenticated token can enumerate, extract, and hand to an attacker before revocation takes effect.

The practical response is to treat API observability as part of identity governance. That means tighter OAuth scope management, field-level response minimisation, and log analytics that can separate normal application traffic from extraction behaviour. For teams building to NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST Cybersecurity Framework, the question is whether access controls actually constrain data movement, not whether they exist on paper.

For practitioners

• Tighten API response minimisation Remove unused metadata fields from externally reachable endpoints and apply per-route field allowlists so that a stolen or abused token cannot expose more than the task requires.
• Revoke and rotate API tokens faster Shorten token lifetimes, enforce rapid revocation for suspected abuse, and block reuse patterns that let attackers continue scraping after initial access has been detected.
• Alert on enumeration and extraction behaviour Baseline normal request patterns, then alert on sequential access, high-frequency endpoint calls, and repeated retrieval of structured user records that indicate automated scraping.
• Treat exposed personal data as phishing fuel Move leaked email and phone data into phishing-risk workflows, including targeted user warnings, account recovery hardening, and support desk guidance for impersonation attempts.

Key takeaways

• This breach shows that exposed APIs can create identity risk even when passwords and payments stay secure.
• The scale of the leak matters because 697,313 records can be repurposed quickly for phishing, impersonation, and account abuse.
• Teams should reduce returned fields, narrow token scope, and monitor extraction patterns before data exfiltration becomes visible.

Key terms

• Delegated API Access: Delegated API access is permission granted to a software actor to act within the authority of a human operator. The important control question is whether the platform enforces the operator’s true entitlement scope at runtime and preserves a clear audit chain back to the requester.
• Token Reuse: Token reuse occurs when the same credential is used across multiple applications, pipelines, or environments. This pattern increases the impact of any single leak because compromise in one place can open access elsewhere. It is a common sign that identity boundaries are too loose for modern automation.
• Data Exfiltration Path: A data exfiltration path is the route sensitive information takes when it leaves an organisation’s controlled environment. In Shadow AI cases, the path may be a prompt field, browser extension, or personal account rather than a file transfer or network event.
• Phishing Amplification: The way stolen personal or contextual data improves the success rate of future phishing, impersonation, or account recovery attacks. Even when passwords are not compromised, exposed contact details and internal metadata can make fraudulent messages far more convincing.

What's in the full analysis

FireCompass's full analysis covers the operational detail this post intentionally leaves for the source:

• MITRE ATT&CK mapping for the phishing-to-exfiltration chain and how the attacker used API access patterns
• Remediation guidance for OAuth token revocation, rotation, and permission hardening across exposed endpoints
• IOC-style indicators from leaked email and phone data that can feed monitoring and triage
• FireCompass's notes on anomalous API call behaviour and token reuse vulnerabilities

👉 FireCompass's full post covers the breach scope, leaked data types, and API-focused remediation guidance

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security practitioners connect identity policy to operational containment across real-world attack paths.