Notifications
Clear all
Topic starter
18/08/2026 2:14 pm
TL;DR: Arbitrary file writes are often treated as low severity, but Ethiack shows that exploitability depends on path control, content control, and knowledge of what the target will later execute. The security gap is reconnaissance, because once the runtime and filesystem are profiled, a write primitive can become code execution.
NHIMG editorial — based on content published by Ethiack: Write Once, Shell Everywhere: Turning Arbitrary File Writes into RCE
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when arbitrary file writes reach reloadable runtime paths?
A: A file write becomes far more dangerous when the target process later reads the file as code or configuration.
Q: Why do arbitrary file writes matter more in containerised environments?
A: Containers remove many legacy execution sinks such as cron, SSH, and interactive logins, but they do not remove runtime reload points or writable application paths.
Q: How can security teams tell whether a file write is becoming an RCE risk?
A: Look for three signals: the write path is predictable, the target file is later re-read or executed, and the writing identity has access to a runtime directory rather than a disposable data folder.
Practitioner guidance
- Tighten write permissions around runtime-owned paths Restrict service accounts and deployment identities so they cannot write into package directories, config roots, template caches, or reloadable code paths.
- Normalise filesystem failure responses Return the same generic error for ENOENT, EACCES, EISDIR, EROFS, and related write failures so attackers cannot use errors as a path oracle.
- Use read-only filesystems for application containers Make the root filesystem read-only and expose only minimal tmpfs locations for scratch space, which removes many of the common AFW-to-RCE sinks.
What's in the full article
Ethiack's full blog post covers the exploit catalog and platform-specific mechanics this analysis intentionally leaves at the source:
- Path-by-path examples for OS, runtime, and framework sinks that can convert file writes into execution
- Fingerprinting techniques that use write failures as a filesystem oracle before choosing a payload
- Specific container and framework cases such as template caches, reloadable configs, and worker entrypoints
- Defender-side mitigations for read-only filesystems, error normalization, and runtime hardening
👉 Read Ethiack's analysis of arbitrary file writes turning into remote code execution →
Arbitrary file writes to RCE: where the real exploitability lives?
Explore further
18/08/2026 3:05 pm
AFW-to-RCE is a reconnaissance problem, not just a file-writing problem. The article shows that impact depends on how much the attacker can learn about the target before choosing a sink. That changes the governance conversation from isolated bug severity to runtime exposure management, because the same primitive can be informational in one environment and catastrophic in another. For practitioners, the real control question is whether filesystem writes can be correlated with execution paths before damage occurs.
A question worth separating out:
Q: What should teams do when a write primitive exists in a production app?
A: Contain the blast radius before attackers can profile the environment. Reduce writable paths, make filesystem errors uniform, remove write access from deployment and service identities, and keep code, templates, and configuration on read-only mounts wherever possible. The goal is to make the write unable to influence any file that a process will later execute.
👉 Read our full editorial: Arbitrary file writes become RCE when runtime paths are predictable
