A core dump is a snapshot of a process’s memory state taken after a crash or forced stop. It can help developers diagnose failures, but it may also contain secrets such as tokens, passwords, or private keys. Defenders should restrict access, control where dumps are written, and ensure they are handled as sensitive data.
What a core dump actually contains
A core dump is not a symbolic error report, it is a memory snapshot captured when a process crashes or is terminated. That means it can preserve stack frames, heap contents, loaded modules, and in some cases the exact data structures the program was using at the moment of failure. The practical value is diagnostic, but the security implication is that whatever the process held in memory may be written out too.
That matters because memory often contains more than application state. A live process may be holding session material, API tokens, passwords entered moments earlier, decrypted payloads, or private keys used for signing or TLS. If the process was handling authentication, encryption, or privileged operations, the dump can expose the same material the application was trying to protect.
How the operating system creates and stores the dump
When a process faults, the operating system can interrupt execution and write the process image to disk or hand it to a crash handler. The exact mechanism varies by platform, but the principle is the same: capture enough state to reconstruct the failure later. Some systems write a file automatically, some route it through a debugger or crash service, and some suppress it unless configuration allows dumps.
Where the dump is written is as important as how it is created. A dump stored in a world-readable directory, left in a shared temp path, copied into ticketing systems, or retained indefinitely becomes sensitive data at rest. If the crash path is automated, the dump may also be replicated to logging, observability, or support tooling, which expands the exposure surface beyond the original host.
Access controls should treat the dump location as a high-value artifact, not as an ordinary troubleshooting file. For related identity and privilege controls, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both reinforce least-privilege handling, secure storage, and controlled recovery of sensitive operational artifacts.
Why core dumps are useful, and why they are risky
Developers use core dumps to reproduce crashes that are otherwise hard to debug. They can show the call stack, corrupted memory, invalid pointers, configuration state, and the exact inputs that led to failure. That makes them invaluable for diagnosing segmentation faults, deadlocks, memory corruption, and unexpected exits in native applications.
The same completeness is what makes them risky. A dump can capture secrets in cleartext even when the application normally protects them in transit or at rest. If the process was privileged, the dump may also reveal internal paths, service credentials, or debugging symbols that help an attacker understand the environment. In practice, a crash artifact can become an accidental exfiltration channel if it is not handled with the same care as a secrets vault export or a database backup.
For teams that routinely investigate memory-related failures, NIST Cybersecurity Framework 2.0 supports the broader governance view, while NIST Privacy Framework is useful when dumps may contain personal data as well as credentials. The control objective is the same: reduce exposure while preserving enough diagnostic value to fix the fault.
Risk and Threat Considerations
Core dumps create a confidentiality risk because they preserve in-memory material that may never have been intended for persistent storage. They also create a trust boundary problem, since a debugging artifact can outlive the crash and move into backup systems, support channels, or developer workstations.
Failure mechanism: Sensitive values are left resident in process memory at the time of the crash, then written to a dump file and exposed through permissive filesystem access, insecure transport, or excessive retention.
Impact: An attacker or insider who obtains the dump may recover tokens, passwords, session material, or keys, then reuse them to impersonate the process or access connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Core dumps need tightly limited read access and controlled handling. |
| AU-11 — Audit Record Retention | Crash artifacts need bounded retention and reviewability as sensitive records. | |
| Recommendation — Restrict dump access to the smallest set of approved operators. Set short, justified retention for crash dumps and track each access. | ||
| NIST CSF 2.0 | PR.DS-1 — Data-at-rest is protected | A dump file is sensitive data at rest that must be protected from disclosure. |
| Recommendation — Encrypt or otherwise protect stored dumps and the systems that hold them. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Dump files may contain secrets and must be classified and protected accordingly. |
| Recommendation — Classify core dumps as sensitive data and enforce secure storage and transfer. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Memory snapshots may expose keys, so cryptographic material handling remains relevant. |
| Recommendation — Ensure key material in memory and dump workflows is protected under crypto handling rules. | ||
Practitioner Guidance
What to verify: Confirm which processes are allowed to generate dumps, where those files land, who can read them, and how long they are retained. If the process handles authentication material, cryptographic material, or customer data, treat the dump path as a regulated data flow rather than a developer convenience.
Decision rule: If a core dump can contain reusable secrets or privileged session state, prioritise access restriction and retention limits before broad distribution to developers or support staff. If the dump is needed for analysis, use a controlled transfer path and a short-lived copy, not an open share or long-lived archive.
Common mistake: Teams often secure the application and forget the crash artifact. That is the wrong order when the dump is more sensitive than the logs, because the dump can preserve plaintext material that the running service would otherwise protect only transiently.
Practitioner takeaway: Treat every core dump as sensitive by default, and only relax that assumption when you can prove the process never handled secrets or other high-value data in memory.
Related resources from NHI Mgmt Group
- What breaks when organisations keep relying on Active Directory as the core model for remote and hybrid work?
- Why do test automation suites become difficult to move even when the core tests still work?
- CVE-2025-48928 (TeleMessage TM SGNL Exposure of Core Dump File to an Unauthorized Control Sphere)
- What is an SVID and how does it work?