A token dump is the disclosure or extraction of access tokens from a system, memory, log, or process. The token can then be replayed to impersonate the original identity and gain whatever API, session, or service access the token carries.
What a token dump means
A token dump is dangerous because access tokens are bearer credentials: once copied, they can often be replayed without re-entering a password or challenge. That makes the theft immediately useful for impersonation, API calls, and session reuse.
The core security issue is not just exposure, but replayability. If the token grants access to an application, service, or account, the attacker can act as that identity until the token expires, is revoked, or is made useless by additional binding controls.
Where token dumps usually come from
Tokens are most often exposed where systems are least able to protect them: process memory, debug logs, crash dumps, browser storage, source code, CI/CD output, and misconfigured telemetry. They can also be pulled from host artifacts after an endpoint or server compromise.
This is why token handling must be treated as a lifecycle problem, not only a storage problem. A token that is safely issued but broadly copied, logged, or cached can still become a reusable credential.
Examples such as the Salesloft OAuth token breach and the Internet Archive breach 2024 show how a stolen token can become an access path long after the original leak.
Why token replay is so effective
Token replay works because many systems trust the token itself as proof of prior authentication. If the token is not sender-constrained, possession alone can be enough to access APIs, sessions, or delegated services from a different device, network, or location.
That trust model makes token dumps attractive to attackers. A single exposed bearer token can bypass password policies, MFA prompts, and normal login friction if the service accepts it as valid credential material.
Modern defenses try to reduce that replay value with audience restriction, proof-of-possession, mutual TLS binding, and shorter lifetimes. Guidance such as the Token and Session Security Guide, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens all address that replay problem from different angles.
What organisations should review after a token dump
Once a token dump is suspected, the first question is scope: which token type leaked, what access it had, where it was used, and whether the associated identity can still act elsewhere. That review should include session logs, API logs, secret stores, code repositories, browser and endpoint artifacts, and any connected integrations.
Post-incident review should also check for hidden persistence. Attackers often use a token once, then create new credentials, add OAuth grants, register apps, or plant automation that survives the original token’s expiry.
The practical lesson is that token leakage often indicates broader identity exposure. A token may be the visible artifact, but the real concern is the access path it opens and the secondary trust it may have established.
Risk and Threat Considerations
Token dumps create immediate access risk because the attacker may not need to crack anything, only reuse a valid bearer credential before it expires or is revoked. They also create stealth risk, since token-based actions can blend into normal API and session traffic.
Failure mechanism: A leaked token remains accepted by the target system, so the attacker replays it from a new context and inherits the permissions, delegation, or session state attached to that token.
Impact: The result can be unauthorized data access, account takeover, service abuse, lateral movement into connected systems, or persistent access if the token or its downstream grants are not invalidated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Token dumps expose bearer credentials that can be replayed as identity material. |
| NHI-04 — Insecure Authentication | Stolen tokens let attackers authenticate without the original user or service present. | |
| NHI-07 — Long-Lived Secrets | Replay risk grows when tokens remain valid long enough to be copied and reused. | |
| Recommendation — Scan, contain, and rotate exposed tokens before attackers can replay them. Bind tokens to context or proof-of-possession so replayed tokens cannot authenticate alone. Shorten token lifetimes and revoke exposed credentials quickly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token dumps are authenticator compromise events requiring lifecycle control and revocation. |
| AC-2 — Account Management | Compromised tokens can preserve access through the account lifecycle and connected grants. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting token abuse depends on reviewing logs for replay and anomalous use. | |
| Recommendation — Manage token issuance, rotation, and revocation to limit replay exposure. Review, disable, and reauthorize accounts and grants after token compromise. Correlate token events and investigate unusual replay patterns in audit logs. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A dumped access token can defeat API authentication when possession alone is accepted. |
| API4 — Unrestricted Resource Consumption | Stolen tokens may be abused to drive automated or high-volume API usage. | |
| Recommendation — Harden API authentication so stolen tokens do not remain sufficient for access. Rate-limit and monitor token-authenticated requests to reduce abuse at scale. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | The term directly describes the credential theft technique used to impersonate an identity. |
| Recommendation — Hunt for token theft activity and correlate it with follow-on account misuse. | ||
Practitioner Guidance
Why practitioners should care: Token dumps are not just secrets exposure, they are often active authentication failures. If a token can be replayed, the organisation should assume the corresponding access path is compromised until proven otherwise.
What to watch for: Treat unexpected token use, unusual geography, new client fingerprints, atypical API volume, and refreshed sessions after leak discovery as signs that the token may already be in abuse.
Practitioner takeaway: The safest response is to revoke or rotate the exposed token and then verify whether the identity behind it created any new grants, sessions, or automation before the leak was contained.
Related resources from NHI Mgmt Group
- What are the signs that a token may be part of a pump-and-dump scheme?
- What happens when token creators dump holdings immediately after launch?
- How should security teams respond when a live session token appears in an underground log dump?
- Why is OAuth token management critical in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org