Dalvik cache is a storage area where Android keeps optimized bytecode generated from application packages. Because cached code may be executed by trusted processes, it can become a dangerous target when attackers can write to it indirectly. Abuse of this cache can help convert file write bugs into execution.
Dalvik Cache as an execution target
Dalvik cache is not just passive storage. On Android, it holds optimized bytecode that trusted runtime components may later load and execute, which means a write opportunity against the cache can have execution consequences rather than simple data corruption. That makes it a security-relevant intermediary between file-system integrity and code execution.
Because the cache sits in the execution path, the important question is not whether an attacker can read it, but whether they can influence what gets written into it, when it is refreshed, or which process consumes it. If an application bug, permission flaw, or filesystem weakness allows that influence, the cache can become part of the attack chain.
How Dalvik cache is used in Android
Dalvik cache exists to improve startup and runtime efficiency by storing pre-processed application code in a form the platform can use more quickly. In practice, it is an optimisation layer, but one that is trusted by the software stack. That trust is what turns a performance feature into a potential security boundary.
The exact implementation varies across Android generations and device builds, but the core idea remains the same: code that originated in an application package is transformed and cached for later execution. Any design that preserves executable material in a writable cache must treat integrity controls as essential, not optional.
Why write access becomes dangerous
The main danger is privilege bridging. A bug that only permits writing to files should not normally lead to code execution, but if the writable target is a cache that later feeds a trusted execution flow, the bug becomes far more serious. Attackers do not need to defeat execution policy directly if they can corrupt a source that the platform already intends to trust.
This is why cache abuse is often discussed as a conversion primitive. It can turn a low-level file-write issue into a much higher-value outcome, such as tampering with code that is subsequently loaded by a privileged or more trusted process.
Exposure, detection, and remediation
Organisations should review any path that allows untrusted code, apps, or sandboxes to influence cache contents, and they should treat unusual writes to executable caches as suspicious. Validation should focus on filesystem permissions, sandbox boundaries, package handling, and whether the cache location is protected from indirect modification.
Detection is strongest when it combines file-integrity monitoring with review of package installation, code-loading behaviour, and unexpected changes to runtime artefacts. If compromise is suspected, responders should assume that any code or session dependent on the affected cache may need validation, because trust may have been extended to malicious content before detection.
Risk and Threat Considerations
Dalvik cache is risky because it sits at the point where stored artefacts become executable behaviour. If an attacker can influence what is cached, they may gain a path from write access to code execution without needing to replace the primary application package itself.
Failure mechanism: Indirect write access, permission weakness, or cache poisoning allows an attacker to alter executable bytecode that a trusted Android process later loads.
Impact: The result can be arbitrary code execution, persistence across launches, or escalation from an apparently limited file-write flaw into a much more serious device compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Dalvik cache integrity directly affects trusted executable content. |
| CM-5 — Access Restrictions for Change | Prevent untrusted processes from modifying cache-backed execution artefacts. | |
| Recommendation — Monitor and validate executable cache integrity before trusted code loads it. Restrict who can change files that influence executable runtime caches. | ||
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | Helps teams recognise cache poisoning and file-write-to-execution abuse patterns. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening storage and permissions reduces indirect modification of executable caches. | |
| Recommendation — Train administrators and developers to spot writable-executable abuse paths. Harden permissions and storage settings around executable cache locations. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | Attackers may place malicious payloads onto a device before execution through trusted paths. |
| Recommendation — Map suspicious cache population to staged payload transfer activity. | ||
Related resources from NHI Mgmt Group
- What is the difference between request-scoped caching and a shared application cache?
- Why can file-integrity checks miss page-cache corruption exploits?
- How should security teams distinguish DNS cache problems from identity access failures?
- When should teams clear DNS cache during incident response?
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 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org